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ABSTRACT 


All  organizations,  both  private  and  public,  must  improve,  streamline,  and 
automate  their  business  practices  to  adjust  to  rigorous  demands  of  a  highly  volatile 
marketplace,  austere  financial  resources,  and  manpower  reductions.  This  thesis  analyzes 
the  potential  of  business  process  reengineering  (BPR)  to  dramatically  improve  the 
Military  Pay  Document  Process  (MPDP)  for  the  United  States  Army  and  the  United 
States  Coast  Guard  financial  communities.  Based  on  Nissen's  methodology  the  MPDP  is 
analyzed  and  three  redesign  alternatives  are  developed,  which  are  capable  of  yielding 
order  of  magnitude  improvements  in  cycle  time  and  cost.  This  thesis  includes  process 
simulation  and  intelligent  systems  analysis  of  the  Army  and  Coast  Guard's  baseline 
MPDP  to  generate  and  evaluate  the  three  redesign  alternatives.  Simulation  runs 
demonstrate  that  cycle  time  and  cost  can  be  reduced  substantially  by  redesigning  the 
MPDP.  The  redesign  alternatives  take  a  comprehensive  look  at  transformation  enablers 
and  information  technology  (IT)  capable  of  eliminating  the  Personnel  Administrative 
Clerks  (PAC)  and  the  finance  office  functions  as  they  pertain  to  pay  transaction 
processing.  The  research  concludes  that  the  Army  and  Coast  Guard's  MPDP  can  be 
dramatically  improved  by  eliminating  middlemen  functions  (PAC  and  finance  office)  and 
shortening  the  value  chain  using  IT  along  with  other  transformation  enablers. 
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L  INTRODUCTION 


Chapter  I  discusses  the  purpose  and  content  of  this  thesis.  It  also  provides  a  brief 
overview  of  the  background  and  objectives  of  the  research,  questions  answered,  and  the 
methodology  used. 

A.  BACKGROUND 

As  the  Department  of  Defense  (DOD)  and  the  Department  of  Transportation 
(DOT)  are  pushed  to  cut  spending  through  downsizing  and  restructuring,  the  need  to 
redesign  existing  military  processes  seems  inevitable.  Recent  government  initiatives 
provide  strong  incentives  for  federal  agencies  to  improve  the  services  they  provide  to  the 
public,  with  greater  accountability  for  achieving  results  quicker  and  at  lower  cost.  The 
1993  Government  Performance  and  Results  Act  establishes  expectations  for  agencies  to 
plan  strategically  and  achieve  better  mission  outcomes.  The  "Contract  With  America", 
with  its  inherent  budget  and  personnel  reductions,  encourages  federal  agencies  to  find 
ways  to  work  more  efficiently  and  effectively.  In  addition,  the  Administration's  National 
Performance  Review  requires  that  federal  agencies  establish  customer  service  standards 
and  focus  efforts  on  improving  the  value  of  government  services  to  the  public.  [A1  Gore, 
1993] 

In  line  with  these  initiatives,  the  Assistant  Secretary  of  the  Army  for  Financial 
Management  (ASA-FM)  announced  in  a  Personnel  Leader’s  Meeting  in  Columbia,  South 
Carolina  on  April  2,  1998  that  she  would  use  five  broad  categories  as  a  framework  to 
communicate  a  variety  of  initiatives.  The  ASA-FM  notes  that,  “Maximizing  information 
technology  is  critical  to  the  success  of  DOD  reengineering  efforts.”  [Helen  T.  McCoy, 
1998]  To  this  end  the  Defense  Finance  and  Accounting  Service  Indianapolis  (DFAS-IN) 
is  preparing  to  test  and  release  a  kiosk  terminal  and  eventually  a  web  based  application 
that  will  allow  service  members  to  access  their  Leave  and  Earnings  Statements  (LES), 
change  allotments,  and  even  change  their  tax  withholdings  options.  The  infusion  of  new 
and  advanced  technology  will  dramatically  change  how  finance  processes  military  pay 
documents. 
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B.  OBJECTIVES 

The  goal  of  our  research  is  to  dramatically  improve  critical  measures  of  process 
performance  which  we  define  as  cost,  customer  service,  and  document  cycle  time  in  both 
the  Army  and  Coast  Guard.  We  do  this  by  redesigning  the  Military  Pay  Document 
Process  of  the  Army  and  Coast  Guard. 

The  Military  Pay  Document  Process  (MPDP)  as  we  define  it  is  the  process  in 
which  the  soldier  or  sailor  can  make  amendments  or  changes  to  his  or  her  Master  Military 
Pay  Account  (MMPA).  Some  examples  of  affected  transactions  include  the  start  and  stop 
of  allotments  for  U.S.  Savings  bonds  or  Life  Insurance  policies,  change  to  tax  exemption 
status,  change  of  financial  institution  or  Direct  Deposits,  and  change  to  employee 
withholding  allowance.  The  bottom-line  is  that  the  customer  (soldier/sailor)  controls  the 
pay  items  just  mentioned.  They  can  only  be  initiated  by  the  soldier/sailor  and  have  a 
direct  impact  on  the  soldiers'/sailors'  MMPA  and  take  home  pay. 

C.  RESEARCH  QUESTIONS 

This  research  is  focused  on  answering  a  primary  question  "How  can  the  Military 
Pay  Document  Process  be  redesigned  to  improve  critical  measures  of  performance?"  In 
order  to  answer  this  question  a  set  of  sub-questions  is  focused  on  and  answered: 

•  What  is  the  current  MPDP? 

•  What  pathologies  and  problems  can  be  observed  in  the  Army  and  Coast  Guard 
MPDP? 

•  How  can  the  MPDP  be  improved  and  what  are  the  expected  performance 
benefits? 

•  What  are  the  MPDP  service  goals  established  by  the  Army  and  Coast  Guard? 

•  How  can  Business  Process  Redesign  (BPR)  help  the  Army  and  the  Coast 
Guard  dramatically  improve  the  MPDP? 

•  What  is  the  most  effective  MPDP  for  the  Army  and  the  Coast  Guard  finance 
communities? 
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D.  SCOPE  OF  THESIS 


The  scope  of  this  thesis  includes  an  overview  of  the  current  Military  Pay 
Document  Processing  Procedures  and  technology,  as  well  as  the  existing  goals  of  the 
Army  and  the  Coast  Guard  financial  communities.  Current  initiatives  to  redesign  the 
Military  Pay  Document  Processing  process  are  examined  along  with  analyzing  existing 
pathologies  and  problems  with  current  customer  service.  This  information  assists  in  the 
redesign  of  the  MPDP  to  improve  critical  performance  measures  for  the  Army  and  the 
Coast  Guard. 

E.  RESEARCH  METHODOLGY 

The  research  techniques  used  for  this  thesis  include  a  thorough  literature  review 
of  the  following  topics:  Business  Process  Reengineering,  Military  Pay  Document 
Process,  Department  of  Defense  Financial  Management,  and  the  Department  of 
Transportation  General  Guidelines  for  customer  service.  A  review  of  selected  Army  and 
Coast  Guard  units’  Standard  Operating  Procedures  is  completed,  surveys  are 
administered,  and  personal  interviews  are  conducted  with  soldiers  and  sailors.  The 
authors  use  Extend  +  BPR  software  to  model  and  simulate  the  MPDP.  We  first  model  the 
baseline  process  of  the  MPDP,  diagnosing  process  pathologies  and  faults,  and  then 
generate  redesign  alternatives. 


F.  CHAPTER  OUTLINE 

This  thesis  is  organized  as  follows.  Chapter  II  provides  background  information 
on  the  evolution  of  the  Military  Pay  System  (MPS)  processes,  and  Business  Process 
Reengineering.  Chapter  III  discusses  the  tools  used  to  develop,  analyze  and  redesign  the 
current  Military  Pay  Document  Process.  Using  these  tools,  the  authors  model  the 
baseline  process,  analyze  process  pathologies  and  measure  the  components  and 
performance  of  the  MPDP.  Chapter  IV  generates  redesign  alternatives,  models  these 
alternatives,  and  analyzes  the  new  process  based  on  the  critical  measures  of  performance. 
Chapter  V  concludes  with  recommendations,  and  future  research  topics. 


3 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


4 


II.  BACKGROUND 


The  mission  of  the  Army  and  the  Coast  Guard  (CG)  finance  community  is  to 
provide  military  pay  support  for  active  duty,  reserve,  and  retired  soldiers  and  sailors  who 
assist  Commanders  in  accomplishing  their  mission.  These  organizations  are  also 
responsible  for  the  computation  and  disbursement  of  travel  allowances,  payment  of 
commercial  vendors,  and  disbursement  of  public  funds  necessary  to  support  the  presence 
of  the  United  States  Army  and  the  United  States  Coast  Guard  in  foreign  areas.  As  one 
can  see,  the  responsibilities  of  these  two  organizations  are  diverse  and  immense.  One  of 
the  most  important  missions  for  both  financial  organizations  is  military  pay  support  for 
active  duty  soldiers  and  sailors  in  the  Department  of  Defense  (DOD)  and  the  Department 
of  Transportation  (DOT)  respectively.  To  accomplish  this  mission  DOD  and  DOT  have 
increased  the  level  of  automation  to  speed  up  the  processes  involved  in  performing 
military  pay  transactions.  Although  automation  has  improved  the  Military  Pay  Document 
Process  (MPDP)  for  the  Army  and  the  CG,  little  has  been  done  to  reengineer  the 
processes  associated  with  the  MPDP. 

The  need  for  reengineering  the  Military  Pay  Document  Process  to  reduce  cost  and 
cycle-time,  and  increase  customer  satisfaction,  has  never  been  greater.  We  can't  continue 
to  embrace  the  Adam  Smith  theory  that  says  people  are  most  efficient  when  they  have 
only  one  easily  understood  task  to  perform.  Hammer  (1993)  points  out  that  simple  tasks 
demand  complex  processes  to  knit  them  all  together,  and  for  many  years  corporations  and 
government  agencies  have  accepted  the  inconvenience,  inefficiencies,  and  costs 
associated  with  complex  processes  in  order  to  reap  the  benefits  of  simple  tasks.  This  way 
of  thinking  is  predicated  on  the  Industrial  Revolution,  when  specialization  of  labor  and 
economy  of  scale  promised  to  overcome  inefficiencies  of  the  cottage  industries.  [Hammer 
and  Champy,  1993] 

Most  of  the  processes  used  by  the  Army  and  the  CG  were  developed  before 
modem  computers  and  communication  systems  existed.  As  the  Army  and  CG  financial 
systems  aged,  processes  (both  documented  and  undocumented)  evolved  to  deal  with  the 
situations  encountered.  Instead  of  being  designed  using  a  structured  approach,  the 
process  mutated  to  what  we  define  as  the  baseline  Military  Pay  Document  Process. 
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A.  MILITARY  PAY  AND  ALLOWANCES 

The  process  of  paying  soldiers  and  sailors  has  a  rich  history  and  interesting 
evolution.  By  examining  the  history  and  the  evolution  of  the  Military  Pay  Document 
Process,  we  can  observe  and  note  the  impact  technology  has  on  these  processes,  while 
examining  how  the  processes  have  changed  in  light  of  technological  advances.  Here  we 
show  that  technology  has  increased  the  speed  and  accuracy,  and  in  some  cases  the 
flexibility,  of  making  pay  changes  for  soldiers  and  sailors;  however  the  process 
associated  with  making  pay  changes  has  changed  very  little,  if  at  all,  in  the  last  century. 

The  current  information  age  has  not  had  the  expected  impact  on  process 
innovations,  since  applying  technology  has  typically  meant  merely  automating  or 
speeding  up  existing  processes.  Two  fundamental  problems  exist  when  this  happens.  The 
first  is  while  processes  might  have  been  improved,  they  were  never  engineered  to  begin 
with.  Secondly,  continuously  improving  existing  processes  simply  means  that  one's  often 
doing  better  what  should  never  have  been  done  at  all.  [Diamond,  1998] 

1.  Evolution  of  the  Military  Pay  Document  Process 

The  U.S.  Army  Finance  Corps  originated  on  June  16,  1775,  when  the  Second 
Continental  Congress  introduced  a  resolution  appointing  James  Warren  as  the  first 
Paymaster  General  for  the  Army.  In  1775  a  captain  received  $20,  a  lieutenant  $13,  a 
sergeant  $8,  and  a  private  $6  each  month.  The  process  of  paying  soldiers  required  the 
Paymaster  at  Army  Headquarters  to  compute  monthly  payrolls  in  his  office  and  then  he 
went  to  the  field  with  his  "box"  of  gold  and  a  military  guard  to  pay  the  soldiers. 
Obviously  payday  was  not  the  1st  and  15th  day  of  each  month,  as  we  know  it  today. 
Furthermore,  soldiers  received  no  additional  entitlements  or  allowances  and  had  no 
control  over  how  their  pay  was  dispersed  or  allotted.  In  a  second  resolution  on  22  June 
1775,  congress  required  General  Warren  to  pay  all  troops  of  the  army  on  a  monthly  basis. 
This  ambitious  requirement  took  more  than  100  years  before  it  could  be  performed 
consistently. 

Since  then  the  Army  has  used  more  modem  methods  for  paying  and  making  pay 
changes  to  soldiers'  pay  accounts.  Over  the  past  five  decades,  the  Army  has  implemented 
four  primary  pay  systems  to  perform  its  mission.  These  four  systems  include  the  Finance 
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Document  Record  Folder  (FDRF)  System,  Joint  Uniform  Military  Pay  System  (JUMPS), 
Jumps  Automated  Coding  System  (JACS),  and  the  Defense  Joint  Military  Pay  System 
(DJMS).  Each  system  and  the  MPDP  associated  with  it  are  discussed  in  the  following 
paragraphs. 

The  Finance  Document  Record  Folder  System  was  implemented  in  the  early 
1900's.  This  was  a  manual  system  that  required  each  finance  office  to  maintain  a  folder 
for  each  soldier  that  was  assigned  to  a  particular  installation.  This  folder  contained  all  the 
financial  transactions  that  were  processed  by  the  finance  office  for  a  soldier.  The 
information  contained  in  this  folder  was  used  to  compute  soldiers'  pay  at  the  end  of  each 
month. 

The  Military  Pay  Document  Process  used  the  FDRF  system:  If  a  soldier  wanted  to 
make  a  change  to  his  account  he  would  report  to  his  Military  Personnel  Office  (Milpo) 
and  retrieve  the  necessary  documentation.  After  the  soldier  completed  the 
documentation,  he  returned  it  to  the  Milpo  clerk.  The  Milpo  clerk  batched  several 
documents  together  (from  other  soldiers)  and  forwarded  them  to  finance  for  processing. 
When  the  documents  arrived  at  the  finance  office,  a  receiving  clerk  reviewed  them  for 
correctness.  Documents  that  were  not  prepared  correctly  were  returned  to  the  unit  that 
sent  them.  If  the  document  was  correct,  a  copy  was  placed  in  the  soldier's  folder.  The 
other  copies  were  batched  together  and  mailed  to  the  United  States  Army  Finance  and 
Accounting  Center  (USAFAC)  in  Indianapolis,  IN  (USAFAC  later  became  the  Defense 
Finance  and  Accounting  Service  (DFAS). 

The  Joint  Uniform  Military  Pay  System  was  implemented  about  1968.  This 
system  took  advantage  of  the  latest  keypunch  technology  to  automate  the  process  of 
making  pay  changes  to  a  soldier's  pay  record.  The  FDRF  was  renamed  the  Personal 
Finance  Record  (PFR).  Each  finance  office  continued  to  maintain  a  PFR  for  each  soldier. 

The  Military  Pay  Document  Process  used  JUMPS:  The  process  didn't  change 
much.  Soldiers  were  still  required  to  go  to  their  Milpo  and  get  advice  and  documents 
from  the  personnel  clerk.  The  preparation  and  routing  of  the  documents  using  JUMPS 
were  virtually  the  same  as  with  the  FDRF  system.  The  difference  in  the  FDRF  and 
JUMPS  was  most  evident  in  the  finance  office.  The  real  difference  is  that  once 
documents  were  inside  the  finance  office,  they  were  married  with  a  soldier's  PFR.  Many 
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PFRs  and  documents  were  placed  on  a  block  ticket  and  forwarded  to  a  finance  clerk  who 
would  prepare  the  keypunch  forms  by  hand  for  each  transaction.  The  block  ticket  with 
the  keypunch  forms  were  forwarded  to  the  quality  edit  section  where  the  forms  were  key 
punched  in  "80-80"  cards.  After  the  keypunch  listings  were  verified  for  correctness,  they 
were  transmitted  to  USAFAC  to  update  a  soldier's  pay  account.  Using  JUMPS  USAFAC 
automated  the  calculation  of  soldiers'  pay. 

The  JUMPS  Automated  Coding  System  was  implemented  about  1983.  JACS 
used  even  more  advance  technology  to  accomplish  the  mission  of  making  changes  to 
soldiers'  pay  accounts.  JACS  hardware  consisted  of  an  IBM  mainframe  at  USAFAC, 
which  centralized  all  soldiers'  pay  accounts,  and  remote  terminals  in  each  finance  office. 
The  PFRs  were  eliminated  and  the  documents  were  coded  in  80-80-card  format  using  the 
remote  terminals.  The  coded  information  was  stored  on  a  local  mini  computer  at  each 
finance  office  until  the  end  of  the  day,  at  which  time  it  was  copied  to  tapes  and 
electronically  transmitted  to  USAFAC  to  change  the  soldier's  pay  account. 

The  Military  Pay  Document  Process  used  JACS:  This  new  system  represented  no 
change  in  the  process.  It  simply  allows  the  old  process  under  JUMPS  to  be  done  faster. 
However,  this  process  added  another  layer  of  controls,  by  requiring  two  coders  to  code 
the  exact  same  document  (The  coders  were  commonly  known  as  "coder  one"  and  "coder 
two").  A  reviewer  verified  both  coders'  transactions  for  correctness.  The  transactions  that 
were  coded  correctly  were  saved  for  later  transmission.  This  additional  layer  of  controls 
negated  any  perceived  benefit  of  automating  the  JUMPS  process.  While  the  objectives  of 
these  controls  may  be  laudable,  many  organizations  fail  to  recognize  the  cost  associated 
with  strict  controls.  [Hammer  and  Champy,  1993]  This  is  a  classic  case  of  embedding 
outdated  processes  in  silicon  and  hardware.  Hammer  (1990)  might  suggest  that  the 
process  be  obliterated  and  use  the  new  technology  to  radically  improve  the  process  not 
just  automate  the  existing  process. 

The  Defense  Joint  Military  Pay  System  was  implemented  about  1994.  This  is  the 
current  system  used  by  DOD.  This  is  a  personal  computer  (PC)  based  system.  There  is  a 
centralized  database  stored  on  an  IBM  mainframe  located  at  DFAS-Indianapolis,  which 
contains  the  master  military  pay  account  (MMPA)  for  each  soldier  in  the  Army. 
Consequently,  a  finance  clerk  via  PC  and  a  direct  connection  from  the  military 
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installation  to  DFAS  can  access  any  soldier's  MMPA.  Under  DJMS  coder  two  was 
eliminated.  However  there  is  still  a  reviewer. 

The  Military  Pay  Document  Process  used  DJMS:  The  soldier  is  required  to  go  to 
his  Personnel  and  Administration  Clerk  (PAC)  to  receive  the  necessary  forms  and  some 
limited  advice.  The  PAC  is  the  same  organization  as  Milpo  with  the  same  basic  function 
—  the  name  just  changed.  PAC  clerks  are  personnel  specialists,  not  finance  specialists; 
therefore  they  are  not  always  able  to  give  the  best  advice  concerning  finance  pay  change 
issues.  The  major  change  is  that  the  documents  are  coded  on  a  PC  downloaded  to  a 
floppy  disk  and  uploaded  directly  to  the  database  at  DFAS-Indianapolis.  The  changes  to 
the  soldiers'  MMPA  are  made  much  faster  once  the  information  is  uploaded  to  DFAS- 
Indianapolis. 

The  Coast  Guard  (CG)  has  experienced  a  similar  evolution  in  its  Military  Pay 
Document  Process  (MPDP)  from  a  manual  system,  called  the  "Yellow  Card",  to  an 
automated  pay  system  called  "Standard  Workstation"  (SWS).  The  CG  has  implemented 
two  different  pay  systems  to  help  improve  the  performance  of  the  pay  mission.  These 
systems  are  the  Yellow  Card  and  JUMPS.  Under  JUMPS  the  CG  has  used  mainframe  and 
dummy  terminal  technology  as  well  as  PC  based  technology. 

The  Yellow  Card  System  was  implemented  in  1915.  This  "card"  looked 
something  like  an  accounting  ledger  and  all  the  transactions  for  a  sailor's  account  was 
recorded  on  it.  The  card  reflected  the  sailors'  base  salary  as  a  credit  and  on  the  15th  and 
30th  of  the  month  when  the  sailor  was  paid  his  card  would  be  manually  annotated  with  a 
debit  for  the  amount  of  the  sailor's  pay. 

The  Military  Pay  Document  Process  used  the  Yellow  Card:  In  the  pre-automated 
days,  the  member  would  go  to  his  unit  Yeoman  and  request  the  necessary  forms  to  make 
a  pay  change.  The  sailor's  unit  Yeoman  forwarded  the  documents  to  the  local  Personnel 
and  Service  Unit  (PERSU).  The  PERSU  Yeoman  manually  posted  the  pay  changes  to 
the  sailor's  yellow  card.  In  the  case  of  an  allotment,  the  form  would  go  to  the  pay  office 
for  posting  to  the  member's  yellow  pay  card.  In  the  case  of  a  marriage,  a  copy  of  the 
marriage  certificate  would  have  gone  to  the  personnel  office  for  an  update  to  the 
member's  service  record.  Then  the  personnel  office  would  have  sent  notice  to  the 
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PERSRU  to  record  the  basic  allowance  for  quarters  (B AQ)  entitlement  on  the  yellow  pay 
card. 

This  process  of  making  changes  to  a  sailor's  card  is  similar  to  the  process  used 
today  to  make  changes  to  a  sailor's  master  military  pay  account  located  in  a  centralized 
database.  With  the  early  yellow  card  system,  there  were  about  500  Yeomen  throughout 
the  CG  that  performed  the  necessary  transactions  for  sailors  each  month. 

Joint  Uniform  Military  Pay  System  (JUMPS)  was  implemented  in  1983.  The 
manual  process  of  recording  sailors'  transactions  was  automated  using  JUMPS.  JUMPS 
allowed  the  CG  to  establish  a  centralized  finance  center  with  200  people  designated  to 
handle  pay  and  personnel  transactions  for  sailors.  This  system  eliminated  many  of  the 
500  Yeomen  used  when  the  process  was  manual.  JUMPS  ran  on  a  Wang  mainframe  and 
used  remote  terminals  at  the  local  PERSUs.  This  system  was  known  as  SWS I. 

The  Military  Pay  Document  Process  used  JUMPS:  As  noted  by  the  Chief  of 
Military  Pay  Support,  Human  Resource  Service  and  Information  Center  (HRSIC), 
Topeka,  KS,  "The  current  automated  process  is  not  much  different  than  when  we  used 
the  yellow  cardboard  pay  cards."  Under  JUMPS  a  sailor  making  changes  to  his  pay 
account  consulted  with  his  unit  Yeoman  who  advised  him  on  financial  matters.  The 
service  member  prepared  the  necessary  documents  and  returned  them  to  the  unit  Yeoman 
who  verified  them  for  correctness.  The  unit  Yeoman  batched  documents  together  and 
forwarded  them,  via  mail,  to  the  servicing  PERSRU  where  a  PERSRU  Yeoman  retrieved 
the  documents.  The  PERSU  Yeoman  verified  the  documents  for  correctness  and  coded 
the  transactions  on  SWS  I.  The  PERSU  Yeoman  then  handed  the  documents  to  a 
transmittal  Yeoman  inside  the  PERSRU.  The  transmittal  Yeoman  electronically 
transmitted  the  coded  information  to  HRSIC  daily.  HRSIC  downloaded  the  information 
file  and  batched  the  transactions  with  transactions  from  other  PERSRUs.  Once  a  week, 
HRSIC  ran  a  batch  job  against  the  master  military  pay  database  to  update  sailors'  master 
military  pay  record. 

Currently  JUMPS  is  being  updated  and  is  now  PC  based  with  better 
communication  access  to  HRSIC  from  the  local  PERSUs.  Although  the  automated 
process  is  a  big  improvement  over  the  manual  process,  the  fundamental  process  has  not 
changed. 
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2.  The  Service  Goals  for  the  Military  Pay  Document  Processing  System 

The  Coast  Guard  and  the  Army  have  established  service  goals  for  the  MPDP.  As 
a  part  of  the  reengineering  process  we  will  consider  the  goals  of  each  service.  The  MPDP 
goals  for  the  Army  are  to  provide  quality  financial  services  to  customers,  reduce  finance 
and  accounting  cost,  provide  the  objective  information  infrastructure,  and  increase  the 
competence  of  financial  management  workforce.  [DFAS,  1998]  The  MPDP  goals  for  the 
CG  are  to  move  personnel  support  closer  to  the  units  serviced,  integrate  procedures  and 
system  configuration,  reduce  process  complexity,  improve  current  personnel/pay 
processes,  provide  flexible  access  to  personnel  and  pay  data,  reduce  annual  operating 
costs.  [Coast  Guard  Goal] 

B.  BUSINESS  PROCESS  REENGINEERING 

Reengineering  originated  in  the  private  sector  as  a  method  for  helping  companies 
sustain  and  preferably  increase  market  shares  in  a  competitive  and  dynamic  marketplace. 
Although  the  reasons  for  change  may  be  different  for  government  -  such  as  increasing 
workload,  shrinking  budgets,  and  personnel  reductions  --  the  need  for  significant 
performance  improvement  is  no  less  imperative. 

1.  Reengineering  Overview 

Business  Process  Reengineering  (BPR)  is  an  approach  to  dramatically  improve 
operating  effectiveness  through  redesigning  critical  business  processes  and  supporting 
business  systems,  as  opposed  to  incremental  improvements.  Hammer  and  Champy 
(1993),  well  known  reengineering  experts  and  creators  of  a  best  selling  book,  define 
reengineering  as  "the  fundamental  rethinking  and  radical  redesign  of  business  processes 
to  achieve  dramatic  improvements  in  critical,  contemporary  measures  of  performance, 
such  as  cost,  quality,  service,  and  speed".  Hammer  and  Champy  provide  further  insight 
into  their  definition  by  identifying  four  key  words:  fundamental,  radical,  dramatic,  and 
processes.  These  key  words  are  discussed  in  detail  in  the  succeeding  paragraphs. 

The  first  word  fundamental  implies  that  organizations  must  clearly  understand 
why  they  exist.  Once  that's  clear,  they  must  intimately  understand  why  they  do  what  they 
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do.  Hammer  and  Champy  suggest  that  organizations  should  answer  two  questions:  Why 
do  we  do  what  we  do?  And  why  do  we  do  it  the  way  we  do?  Government  organizations 
are  especially  guilty  of  operating  according  to  ad  hoc  rules,  which  have  evolved  over 
time  but  are  no  longer  are  appropriate.  Military  organizations  are  notorious  for  writing 
pages  of  standard  operating  procedures,  which  are  rules  governing  the  way  an 
organization  operates.  However,  most  of  these  SOPs  are  out  dated  and  have  little 
congruency  with  the  current  organizational  environment  or  customer  needs.  By 
redesigning  processes  new  SOPs  will  emerge  focused  on  customers  and  their  needs, 
ignoring  what  is  and  concentrating  on  what  should  be.  [Hammer  and  Champy,  1993] 

The  second  key  word  is  radical.  This  word  is  derived  from  the  Latin  word 
"radix"  meaning  root.  Getting  at  the  root  of  the  problem,  finding  out  what  makes  the 
process  work  the  way  it  does  and  why  it  has  to  be  done  that  way.  Hammer  suggests  that 
outdated  processes  should  be  obliterated  and  redesigned  properly  from  scratch.  [Hammer, 
1990]  Hammer  and  Champy  (1993)  characterize  reengineering  as  a  "clean  sheet" 
approach  to  radical  change.  The  clean  sheet  approach  draws  direct  contrast  to  the 
incremental  approach  of  process  improvement. 

Process  improvement  is  about  enhancing  or  improving  existing  processes. 
Consequently  one  may  improve  or  speed  up  a  process,  with  automation,  that  should  never 
have  been  done  in  the  first  place.  Hammer  suggests  that  "it's  time  to  stop  paving  the  cow 
path  and  use  computers  to  redesign  -  not  just  automate  existing  processes."  [Hammer, 
1990]  Reading  the  evolution  of  the  MPDP  for  the  Army  and  the  CG,  one  can  see  that  the 
current  MPDPs  in  both  services  are  simply  old  processes,  which  have  been  speeded  up 
using  automation.  Although  some  improvements  have  been  made  in  the  process  speed, 
dramatic  improvements  will  require  radical  changes  in  the  process. 

The  key  word  dramatic  enforces  the  notion  that  BPR  is  not  about  making 
marginal  or  incremental  improvements,  but  about  achieving  quantum  leaps  in 
performance.  Organizations  expect  an  order  of  magnitude  in  performance  gains  from  a 
reengineering  approach.  While  some  may  debate  it,  most  experts  would  agree  that 
reengineering  is  an  all  or  nothing  proposition  that  delivers  major  gains  in  performance. 
In  order  to  achieve  this  sort  of  performance  improvement,  the  Army  and  the  CG  finance 
community  must  "break  away  from  conventional  wisdom  and  constraints  of 
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organizational  boundaries".  [Hammer  and  Champy,  1993]  Dr.  Sharon  L.  Caudle  (1995), 
who  wrote  her  dissertation  on  her  experiences  with  reengineering  government  agencies, 
suggests  that  processes  cross  functional  units  and/or  organizational  boundaries  to  involve 
other  organizations  or  individuals.  In  fact,  a  business  process  is  basically  independent  of 
formal  organizational  structural  arrangements  and  reporting  relationships.  A  process  is 
how  the  organization  delivers  value  to  the  customers,  regardless  of  the  hierarchy  and 
vertical  structural  designs.  For  most  military  managers  who  are  anchored  to  their 
functional  area,  this  is  a  very  different  view.  Caudle  says  the  "functional  foxholes"  of 
areas  such  as  personnel,  finance,  budgeting,  operations,  and  evaluation  must  be 
transformed  into  "process  streams".  Organizations  as  traditional  as  the  military  must 
replace  their  vertical  view  of  independent  functions  with  a  horizontal  view  of  many 
interlocking  processes.  [Caudle,  1995] 

Based  on  Caudle's  studies  of  government  organizations  and  their  composite 
experiences,  she  has  developed  a  definition  for  government  reengineering. 

Government  business  process  reengineering  is  a  radical 
improvement  approach  that  critically  examines,  rethinks,  and  designs 
mission-delivery  processes  and  sub-processes.  In  a  political  environment, 
it  achieves  dramatic  mission  performance  gains  from  multiple  customers 
and  stakeholder  perspectives.  It  is  a  key  part  of  a  process  management 
approach  that  continually  evaluates,  adjusts,  or  removes  processes  or  sub¬ 
processes  for  optimal  performance. "[Caudle,  1995] 

There  are  other  reengineering  practitioners  who  have  come  up  with  their  own 
definitions  for  reengineering.  In  essence,  they  boil  down  to  a  systematic  approach,  not 
necessarily  done  the  same  way  by  everyone,  that  allows  managers,  subordinate  managers, 
and  line  workers  to  fundamentally  reexamine,  rethink,  and  redesign  old  ways  of  doing 
business  -  achieving  dramatic,  measurable  improvements  in  critical  measures  of 
performance.  Reengineering  is  about  fundamental  change. 

While  scholars  and  non-scholars  may  define  reengineering  slightly  different,  most 
will  agree  that  customers  ultimately  define  value,  and  without  a  customer  focus,  an 
organization  risks  missing  what  matters  most  in  achieving  its  mission.  They  will  also 
agree  that  reengineering  critically  examines  the  underlying  assumptions  about  how  an 
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organization  conducts  its  work,  examining  not  only  the  work  processes,  but  the 
underlying  business  rules  that  dictate  how  work  is  performed.  Although  reengineering 
can  be  a  highly  complex  and  high-risk  endeavor,  organizations  that  have  reengineered 
successfully  generally  followed  a  set  of  identifiable  practices  and  a  sound  methodological 
approach.  While  reengineering  reaches  far  beyond  business  process  to  achieve  the 
dramatic  performance  gains,  it  is  not  a  panacea;  it  is  one  element  of  a  comprehensive 
process  management  program.  [GAO,  1995] 

The  desired  outcome  of  reengineering  is  a  customer-focused  organization  that 
experiences  extraordinary  gains  in  productivity.  "Reengineering  —  with  its  radical 
changes  in  areas  such  as  work  flow,  rules  and  regulations,  job  content,  job  skills, 
decision-making,  and  information  systems  -  is  the  only  thing  that  can  bring  about 
[dramatic]  improvement  in  either  the  total  process  or  a  process'  major  sub-processes." 
[Caudle,  1995] 

2.  What  Will  Be  Measured? 

Business  process  reengineering  is  a  structured  approach  that  relies  on 
performance  measurement  to  determine  which  process  to  reengineer  and  to  determine  if 
proposed  changes  will  have  a  productive  impact.  Performance  measurements  are  defined 
in  this  thesis  as  an  indicator  that  can  be  used  to  evaluate  quality,  cost,  or  cycle  time 
characteristics  of  an  activity  or  process  usually  against  a  target  or  standard  value.  It  is  an 
established,  consistent  way  to  measure  the  rate  of  change  within  an  organization. 
However,  performance  measurements  alone  do  not  provide  enough  insight  to  redesign  the 
process  to  improve  performance.  Consequently,  a  means  for  measuring  the  components 
of  the  process,  identifying  process  pathologies,  and  identifying  possible  redesign 
alternatives  is  needed.  The  tool  used  to  accomplish  this  is  called  KOPeR.  This  tool  is 
discussed  in  detail  in  Chapter  III.  The  authors  will  measure  the  MPDP  performance 
using  the  performance  measurements  in  Table  1  and  the  process  components  using  the 
measures  in  Table  2. 
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Table  1  Performance  Measures 


Measurements 

Definition 

Cycle  Time 

The  measurement  of  the  time  an  item  remains  in  the  process, 
either  in  the  entire  process  or  in  a  specific  part  of  it.  Cycle  time 
measures  how  long  it  takes  to  get  from  point  A  to  point  B  (e.g., 
beginning  to  end). 

Cost 

The  price  or  imputed  value  of  each  resource  assigned  to  an  activity 
that  is  consumed  in  the  process  of  producing  the  products  and 
services  of  that  activity. 

Quality  of  Service 

The  traditional  definition  states  that  quality  is  the  degree  of 
excellence  possessed  by  a  product,  service,  or  other  output  of  a 
business  activity  or  business  process.  We  define  quality  as,  how 
well  the  process  conforms  to  the  customers'  requirements. 

Table  2  Process  Measures  [Nissen,  1994] 


Measure 

Definition 

Process  Length 

Number  of  nodes  in  longest  path 

Process  Breadth 

Number  of  distinct  paths 

Process  Depth 

Number  of  process  levels 

Process  Size 

Number  of  nodes  in  process  model 

Process  Feedback 

Number  of  cycles  in  process  graph 

Parallelism 

Process  Size  divided  by  Length 

IT  Support 

Number  of  IT-support  attributes 

IT  Communication 

Number  of  IT-communication  attributes 

IT  Automation 

Number  of  IT-automation  attributes 

Process  Handoffs 

Number  of  inter-role  edges 

Value  Chains 

Number  of  unique  activity  Value  Chain  attributes 

3.  How  Will  The  MPDP  Be  Changed? 

To  achieve  the  dramatic  improvements  that  BPR  can  bring,  the  authors  consider 
making  changes  to  the  MPDP  by  eliminating  non-essential,  non-value-adding  steps, 


15 


implementing  and  inserting  technology  where  appropriate,  improving  workflow  to 
emphasize  value-adding  functions,  providing  metrics  for  meaningful  analysis  and 
strategic  planning,  moving  pay  support  closer  to  the  customer,  reducing  current  system 
complexity  that  drive  cost,  combining  several  jobs  into  one,  reducing  unnecessary  checks 
and  controls,  and  allowing  work  to  be  performed  where  it  makes  the  most  sense. 
[Hammer  and  Champy,  1993] 

Service  organizations,  such  as  the  financial  communities  of  the  Army  and  the  CG, 
must  put  their  professed  commitment  to  customer  satisfaction  at  the  center  of  the 
redesign  effort.  In  government  organizations,  the  authors  note  from  their  own 
experiences  that  service  workers  or  finance  clerks  are  unable  to  satisfy  the  customer 
because  they  must  follow  strictly  defined  rules,  and  lack  the  authority  to  make  exceptions 
or  the  resources  to  complete  a  transaction.  Therefore,  the  authors  seek  to  redesign  the 
MPDP  making  the  customer  the  starting  point  for  change. 

4.  Overview  of  Business  Process  Redesign  Methodologies 

Our  research  efforts  to  find  a  structured  approach  to  BPR  left  us  somewhat  empty 
handed.  Although  there  are  many  opinions  and  keen  insight  to  BPR,  there  is  little  detail 
about  what  specific  steps  to  take  to  reengineer  the  identified  processes.  However,  Sharon 
Bitzer's  (1995)  thesis,  Workflow  Reengineering:  Business  Process  Reengineering  with 
Workflow  Management  Technology,  does  an  excellent  job  evaluating  four  different 
methodologies  from  four  different  BPR  practitioners.  The  four  published  methodologies 
evaluated  by  Bitzer  are  from  Mark  Klein,  Thomas  Davenport,  H.  J.  Harrington,  and  the 
Department  of  Defense.  The  authors  encourage  the  reader  to  examine  each  methodology 
in  more  detail  prior  to  beginning  a  reengineering  project.  The  intent  of  the  authors  is  to 
review  the  evaluation  made  by  Bitzer  and  determine  an  appropriate  methodology  to  use 
in  redesigning  the  MPDP. 

Bitzer  compares  each  methodology  against  the  characteristics  outlined  in  the 
Department  of  Defense  (DOD)  manual  on  business  process  reengineering.  According  to 
Bitzer,  DOD  states  that  an  effective  methodology  for  change  must  conform  to  the  items 
in  Table  4  (DODINST  8020. 1-M,  1993). 
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Table  3  DOD  Characteristics  of  an  effective  methodology 


Item 

Definition 

Complete: 

It  must  provide  steps  that  direct  a  business  process  improvement 
procedure  from  establishment  to  implementation. 

Applicable: 

The  methodology  must  be  able  to  be  used  on  any  process  of  the 

business. 

Friendly: 

The  procedure  must  be  easy  for  all  personnel,  including  non¬ 
technical  workers  and  managers,  to  learn  and  understand. 

Consistent: 

It  must  be  the  only  method  used  to  conduct  reengineering  within 
the  organization.  This  will  allow  in-house  reengineering 

•expertise  to  be  developed. 

Supported: 

The  engineering  procedure  must  include  detailed 
documentation,  training  courses  and  project  management  tools. 

Successful: 

The  methodology  should  have  a  record  of  success  and  these 
cases  should  be  available  to  guide  the  actions  of  the 

reengineering  team. 

Documenting: 

The  procedures  must  produce  process  documentation  as  it  is 

used. 

Enabling  by  Tools: 

The  method  must  be  supported  by  automated  tools  that  help  ease 
the  reengineering  workload  and  enable  process  documentation 

and  measurement 

Bitzer  (1995)  concluded  in  her  evaluation  of  the  four  methodologies  that  Klein's, 
Davenport's,  and  Harrington's  methodologies  do  not  exhibit  all  the  characteristics  of  an 
effective  methodology.  Bitzer  rejects  Klein's  methodology  because  it  does  not  specify 
any  tools,  automated  or  not,  and  it  gives  no  examples  of  the  methodology's  success. 
Davenport's  methodology  is  rejected  because  "it  is  not  comprehensive".  Bitzer  notes  that 
Davenport  fails  to  specify  steps  for  gaining  management  support.  He  focuses  most  of  his 
attention  on  gaining  a  greater  understanding  about  what  the  process  should  do,  while  his 
methodology,  in  Bitzer's  opinion,  lacks  direction  on  how  to  identify  changes  to  a  process. 
Bitzer  suggests  that  Harrington's  methodology  is  the  most  complete.  While  furnishing 
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detailed  steps,  Harrington  provides  guidance  on  how  to  organize  for  improvement,  what 
data  should  be  collected  prior  to  analyzing  a  process,  and  he  provides  guidance  on  how  to 
improve  the  process.  However,  Bitzer  also  rejects  Harrington's  methodology  because  it 
does  not  specify  computerized  software  tools  to  be  used  during  the  redesign  process,  nor 
does  it  mention  any  simulation  tools  used  prior  to  implementation.  Of  all  the 
methodologies  evaluated,  Bitzer  noted  DOD's  methodology  as  being  the  most 
comprehensive  and  the  one  that  most  closely  exhibits  the  characteristics  of  an  effective 
methodology.  Bitzer  evaluated  DOD's  methodology  as  the  best.  However  she  noted  that 
the  modeling  tool  specified  for  use  by  the  methodology  is  complicated  and  lacks  the 
integration  of  process  modeling,  cost  analysis,  and  simulation. 

A  methodology  not  included  in  Bitzer's  thesis  is  one  developed  by  Nissen.  This 
methodology  is  a  unique  blend  of  several  of  the  methodologies  discussed  above.  As 
noted,  all  above  methodologies  contain  some  faults.  Most  importantly,  Nissen's  synthesis 
of  several  expert  methodologies  creates  a  methodology,  which  supports  process 
measurements  with  "rigor  and  precision".  [Nissen,  1997] 

5.  Methodology  Used  To  Redesign  MPDP 

Following  these  steps,  the  authors  use  Nissen's  methodology  (see  Figure  1)  to 
redesign  the  MPDP.  The  steps  associated  with  this  methodology  are  as  follows: 

1 .  Identify  the  process 

2.  Model  the  process 

3.  Measure  the  configuration 

4.  Diagnosis  the  pathologies 

5.  Match  the  transformations 

6.  Generate  redesign  alternatives 

7.  Test  redesign  alternatives 

8.  Select  preferred  choice 

The  authors  identified  a  sub-process  of  the  Military  Pay  System  for  the  United 
States  Army  and  the  United  States  Coast  Guard.  The  MPDP,  defined  in  Chapter  I,  was 
chosen  because  it  presents  an  excellent  opportunity  for  dramatic  improvement.  Experts 
suggest  the  reengineering  should  consider  processes  with  the  most  possibility  for 
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dramatic  improvement.  Based  on  one  author's  first  hand  knowledge  and  nine  years  of 
experience  as  a  finance  officer,  he  concludes  that  reengineering  the  MPDP  has  potential 
for  dramatic  improvement.  Using  Extend  +  BPR  modeling  and  simulation  software  the 
authors  model  the  baseline  (i.e.,  "as-is")  process  and  measure  the  process  cost,  cycle  time, 
and  quality  (see  Table  2).  Using  KOPeR  (pronounce  "cope-er")  the  baseline  process 
configuration  is  measured  (see  Table  3  Process  Pathologies).  These  measurements  "drive 
the  diagnosis  of  process  pathologies"  (see  Table  5).  [Nissen,  1997]  After  measuring  the 
process  and  diagnosing  the  pathologies  we  "treat"  the  pathologies  by  matching  the 
redesign  transformations  (see  Table  4  Redesign  Transformations)  available.  During  this 
step  the  authors  look  at  technology,  workflow,  and  information  available  to  improve  the 
process.  Based  on  the  diagnosis  and  treatment  recommendations,  redesign  alternatives  are 
developed.  Using  Extend  +  BPR,  the  critical  performance  measures  of  the  redesigned 
alternatives  are  compared  with  those  of  the  baseline  model  to  determine  if  treatment  was 
effective.  By  testing  the  redesign  alternatives,  using  modeling  and  simulation, 
performance  is  compared  to  the  baseline  benchmark  to  determine  the  performance 
improvement.  KOPeR  and  Extend  +  BPR  tools  are  discussed  in  Chapter  III.  [Nissen 
1997] 


Figure  1  -  Redesign  Process  Methodology  (KOPeR  approach) 
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III.  MODEL  DEVELOPMENT  TOOLS  AND  "AS-IS"  PROCESS 


A.  MODEL  DEVELOPMENT  TOOLS 
1.  EXTEND 

EXTEND  +  BPR  modeling  and  simulation  software  is  used  to  model  the  MPDP 
and  assesses  the  performance  of  the  baseline  process  as  well  as  the  relative  performance 
improvements  of  the  process'  redesign  alternatives  discussed  in  Chapter  IV. 

a.  EXTEND  Overview 

EXTEND  +  BPR  is  an  object-oriented  environment  for  modeling, 
analyzing,  reengineering,  and  documenting  processes.  It  uses  an  iconic  building-block 
paradigm  to  facilitate  communication  and  allows  the  authors  to  concentrate  more  on 
process  design  than  on  any  particular  methodology.  The  MPDP  is  composed  of  real- 
world  elements  and  processes  that  interact  when  specific  events  occur.  Using  EXTEND 
+  BPR,  the  authors  are  able  to  simulate  the  MPDP  system  using  blocks  which  mimic  the 
real-life  processes  and  timing  that  represent  the  actual  occurrence  of  events.  The  blocks 
used  in  EXTEND  +  BPR  directly  correspond  to  the  activities  (coding  documents),  queues 
(in/out  boxes),  delays  (cycle  time),  and  transformations  that  comprise  the  process  to  be 
redesigned. 

Using  EXTEND  +  BPR  the  authors  can  easily  incorporate  high-level 
reengineering  concepts  such  as  batching,  cycle  timing,  activity-based  costing,  and 
conditional  routing.  This  software  is  excellent  for  the  redesign  of  the  MPDP,  for  it  de¬ 
mystifies  modeling  and  simulation  and  allows  non-technical  personnel,  such  as  managers 
and  the  people  who  do  the  work,  to  utilize  simulation  for  analysis  and  redesign  of 
business  processes.  The  authors  use  this  software  to  assist  in  answering  the  primary 
question  proposed  by  this  research:  How  can  the  Military  Pay  Document  Process  be 
redesigned  to  improve  critical  measures  of  performance  such  as  cost,  cycle  time,  and 
customer  service.  Measurements  and  predictions  about  cycle  time,  cost,  quality,  and  the 
cost  of  implementing  alternatives  serve  as  a  basis  for  developing  high-performance 
alternatives  that  can  get  the  Army  and  the  CG  financial  communities  from  the  "as-is"  to 
the  "to-be".  However,  developing  a  specific  strategy  to  go  from  the  "as-is"  to  the  "to-be" 
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design  is  beyond  the  scope  of  this  thesis  and  is  recommended  for  future  research. 
Following  the  redesign  methodology  discussed  above  the  authors  use  the  information 
obtained  from  KOPeR  and  EXTEND  +  BPR  simulation  to  generate  and  test  promising 
redesign  alternatives. 

b.  Input  Variables  for  EXTEND 

EXTEND  requires  input  data  and  variables  to  drive  the  model.  Time 
dependent  data  such  as  document  arrival  time  and  document  review  time  is  one  type  of 
data  that  is  necessary.  The  other  type  of  data  is  probabilistic  data  -  data  such  as  the 
probability  of  a  document  being  rejected  by  the  finance-receiving  clerk.  These  variables 
allow  the  authors  to  measure  cycle  time.  Cost  data  is  also  important  to  compare  relative 
cost  of  process  alternatives.  To  obtain  the  input  variables  the  authors  consulted  with  an 
Army  finance  unit  (Table  4  Input  Variables  -  US  Army)  and  a  Coast  Guard  PERSRU 
(Table  5  Input  Variables  -  US  Coast  Guard).  The  input  variables  are  a  result  of 
interviews  with  senior  finance  personal  who  are  intimately  familiar  with  the  details  of  the 


MPDP. 

Table  4  Input  Variables  -  U.S.  Army 


Variables 

Distribution /Value  (avg.) 

Source  (averages) 

PAC  Process 

...  •  „  v-  ./  v  *  ;  >s’\ v  . 

Document  arrival  rate  - 
PAC 

5  min  (per  document) 

Expert  estimate 

Document  review  rate  - 
PAC 

6  min  (per  document) 

Expert  estimate 

Prepare  Transmittal  Letter 

1  min  (per  document) 

Expert  estimate 

Number  of  Documents 
remaining  in  the  PAC's 
inbox  from  the  prior  day 

4  per  day 

Expert  estimate 

Delay  time  for  unit  PAC  to 
courier  documents  to 
finance 

30  min 

Expert  estimate 
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Finance  Process 

:  ;•  ,  r  ;'-r  . 

PAC  arrival  rate  -  Finance 
Office 

15.45  min 

Expert  estimate 

Document  review  rate  - 
Finance  Office 

5.25  min 

Expert  estimate 

Document  processing  rate  - 
Finance  Office  (per 
coder/per  batch) 

17.14  min 

Expert  estimate 

Hourly  regular  military 
compensation. 

$9.03/per  hour 

1999  Pay  Tables  (E-4 
with  3  years  of  service) 

Table  5  Input  Variables  -  U.S.  Coast  Guard 


Variable 

Distribution/V  alue  (avg.) 

Source 

Unit  Yeoman  Process  k; 

Document  arrival  rate  -  unit 
Yeoman 

30  min  (per  document) 

Calculated  from  data 

Document  review  rate  -  unit 
Yeoman 

5  min  (per  document) 

Expert  estimate 

Number  of  Documents 
remaining  in  the  Yeoman's 
inbox  from  the  prior  day 

3  per  day 

Expert  estimate 

Delay  time  for  unit  Yeoman 
to  courier  documents  to 
finance 

3.5  hours 

Expert  estimate 

PERSRU  Process 

TL  arrival  rate  -  PERSRU 

1 8  min  (per  TL) 

Expert  estimate 

Document  review  rate  - 
PERSRU 

10  min  (perTL) 

Expert  estimate 

Document  processing  rate  - 
PERSRU  (per  coder/per 
batch) 

20  min  (per  TL) 

Expert  estimate 

Hourly  regular  military 
compensation 

$10.3 8/per  hour 

1999  Military  Pay  Tables 
(E-5  with  5  years  of 
service) 
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The  exponential  function  is  widely  used  to  analyze  times  between 
independent  events  such  as  arrival  times.  Many  phenomena  are  exponentially 
distributed,  such  as  the  times  between  arrivals  of  aircraft  to  an  airport  and  the  time 
between  documents  arriving  at  the  finance  office.  [Pegden,  Shannon  and  Sadowski,  1995] 
Pegden,  Shannon  and  Sadowski  (1995)  note  that  when  determining  input  variables, 
reliance  on  the  following  sources  may  prove  to  be  the  best  option:  1)  operators,  2)  vendor 
claims,  and  3)  theoretical  considerations.  Therefore  it  is  assumed  that  the  document  for 
the  MPDP  arrival  time  is  exponentially  distributed.  The  document  arrival  time  for  the 
Army  PAC  is  5  minutes  per  document.  PAC  clerks  arrive  at  the  finance  office  with  a 
batch  of  documents  every  15.45  minutes.  The  document  arrival  time  is  also  exponentially 
distributed  for  the  CG  with  one  document  arriving  at  the  unit  yeoman's  office  every  30 
minutes  and  a  unit  yeoman  arriving  at  the  PERSRU  with  a  batch  of  documents  every  18 
minutes. 

2.  KOPeR 

a.  Overview 

Knowledge-based  systems  (KBSs)  are  used  to  support  process  redesign. 
KOPeR  (knowledge-based  organizational  process  redesign  -  pronounced  "cope-er")  is  a 
proof  of  concept  system  KBS,  which  provides  an  automated  reengineering  method  to 
evaluate  redesigned  alternatives.  "The  KOPeR  design  draws  from  the  artificial 
intelligence  (AI)  methods  and  technologies,  which  allow  it  to  capture  process  redesign 
knowledge  from  the  reengineering  literature  and  practice  through  twin  taxonomies  and 
production  rules."  [Nissen,  1997] 

Nissen  defines  KOPeR  as  a  graphed  based  tool  (i.e.,  comprised  of  nodes, 
edges,  and  attributes),  which  produces  a  battery  of  graph-based  diagnostic  process 
measures  automatically.  As  diagnostics  these  measurements  are  used  to  detect  severe 
pathologies  and  faults  associated  with  a  process.  KOPeR  employs  a  base  of  formalized 
reengineering  knowledge  (i.e.,  knowledge  base)  to  predict  which  design  transformations 
are  most  likely  to  effect  dramatic  improvement  in  process  performance.  These 
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transformations  are  then  applied  to  the  baseline  (i.e.,  "as-is")  process  model  to  generate 
one  or  more  re-design  alternatives.  [Nissen,  1997] 

Once  the  process  model  has  been  validated  and  calibrated  against  the 
process  baseline,  EXTEND  +  BPR  simulation  software  is  used  to  test  the  performance  of 
each  redesign  alternative.  Combining  the  KOPeR  model  with  EXTEND  +  BPR 
represents  an  efficient  technique  when  evaluating  alternate  process  redesigns,  and  it  helps 
reduce  the  inherent  risks  of  reengineering  by  providing  a  method  to  evaluate  redesign 
alternatives  before  committing  time  and  money. 


b.  Input  Variables 

Simulating  the  baseline  process  using  EXTEND  +  BPR  provides  a 
graphical  depiction  of  the  process  for  applying  KOPeR.  The  graphical  depiction  of  the 
process  is  used  to  calculate  the  measures  for  the  MPDP  "as-is"  and  "to-be"  process  (i.e., 
steps,  length,  breadth,  depths,  size,  feedback,  parallelism,  handoffs,  information 
technology  support  (IT-S),  information  technology  communication  (IT-C),  and 
information  technology  automation  (IT-A)).  Figure  2  shows  an  example  of  how  graph 
based  measurements  can  be  used  to  represent  the  inputs  to  KOPeR  for  redesign.  [Nissen, 
1994] 
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Measurements 

Length  =  4  Breadth  =  1  Depth  =  1  Handoffs  =  3 
Size  =  4  Feedback  =  1  Parallelism  =  1 .00 
IT-support  =  3  IT-cpmmunicatiQnr.Q  IT-automation  =  0 


Figure  2  -  Process  Model 


In  order  to  evaluate  these  measures,  a  Level  1  and  Level  2  baseline 
representation  is  developed  for  each  organization.  Then  the  input  variables  needed  for 
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KOPeR  are  calculated  as  described  in  Chapter  II,  Table  2.  In  the  following  two  sections 
we  begin  the  first  step  of  Nissen's  methodology  by  describing  the  "as-is"  MPDP  for  the 
Army  and  the  CG. 

B.  UNITED  STATES  ARMY  MILITARY  DOCUMENT  PROCESS 

This  section  describes  the  "as-is"  MPDP  for  a  United  States  Army  finance  unit 
providing  pay  support  to  soldiers  co-located  on  the  same  installation.  Although  the 
process  description  is  that  of  a  particular  finance  unit,  it  reflects  the  process  flow  of  most 
finance  units. 

1.  "AS-IS"  Process  Description 

The  U.S.  Army  MPDP  is  a  linear  batch  process.  Soldiers  create  documents  by 
requesting  pay  changes.  The  documents  are  given  to  the  soldier's  unit  personnel  and 
administration  clerk  (PAC),  who  couriers  the  documents  to  the  finance  office  for 
processing.  At  the  finance  office  the  documents  are  reviewed,  coded,  and  transmitted  to 
DFAS.  At  DFAS  the  documents  are  processed  against  the  soldier's  master  military  pay 
account  (MMPA).  A  level  1  schema  of  this  is  represented  in  Figure  3.  Figures  4  and  5 
show  the  decomposition  of  the  PAC  processes  and  the  finance  office  process 
respectively. 


Figure  3:  US  Army  level  1  schema  ("AS-IS") 


The  detailed  process  is  as  follows:  A  soldier  decides  he  wants  to  initiate  a  pay 
change  (Typical  pay  transactions  are  listed  in  Table  6).  The  soldier  reports  to  his 
personnel  and  administration  clerk  (PAC)  to  retrieve  the  necessary  forms.  In  some  cases 
the  form(s)  can  be  downloaded  from  the  World  Wide  Web  (WWW).  The  soldier 
prepares  the  document(s)  and  returns  it  to  the  PAC.  The  PAC  reviews  the  document(s) 
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for  completeness  and  correctness  and  batches  it  with  other  documents  received  from 
other  soldiers.  The  PAC  covers  the  batched  documents  with  a  transmittal  letter  (TL) 
which  lists  all  the  documents  in  the  batch  and  couriers  the  documents  to  the  finance 
office. 


Figure  4  Unit  PAC  Process  (decomposition) 


A  receiving  clerk  at  finance  reviews  the  documents  again  for  completeness  and 
correctness.  Documents  that  are  not  prepared  correctly  are  given  back  to  the  PAC  clerk. 
The  receiving  clerk  takes  the  documents  to  the  coding  section  where  they  are  sorted  by 
type  and  placed  in  a  document  bin.  Coders  retrieve  documents  from  the  document  bin 
and  process  them.  At  the  end  of  the  day  the  coder  saves  the  coded  transactions  onto  a 
floppy  diskette,  makes  a  hardcopy  printout  of  the  coded  transactions  and  gives  the 
hardcopy  and  the  documents  to  the  auditor. 
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Figure  5  Finance  Office  Process  (decomposition) 


The  auditor  reviews  the  coded  transaction  given  to  him  by  the  coder  and  transmits  them 
to  DFAS-IN  to  process  against  the  soldier's  MMPA.  If  the  transactions  are  without  error 
the  changes  are  reflected  on  the  soldiers  MMPA.  If  any  uploaded  transaction  is  in  error, 
the  transaction  is  rejected  and  is  re-worked  by  the  coder.  These  errors  are  generally 
corrected  immediately  with  minimal  addition  to  the  processing  time. 


Table  6  Typical  Pay  Transactions 


DA  Form  3685  N/A  Direct  Deposit  Deposits  Money  To 


specified  Financial 
Institution  or  Bank 
Accounts 
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DD  Form  2558 

N/A 

Allotment 
(stop/start/ change) 

Deducts  money  out  of 
sailors  pay  and  sends  it 
where  directed 
(Insurance  Company,  U. 

S.  Savings  Bond 
purchase.  Mortgage 
Payment,  or  Individual) 

DD  Form  2058-1 

DD  Form  2058-1 

Tax  exemption 
status. 

Allows  sailor  to  change 
his  tax  exemption  status. 

DD  Form  2559 

DD  Form  2559 

Savings  Bond 
Allotment 

Deducts  Money  from 
soldiers  pay  to  purchase 
savings  bonds  for 
soldier. 

2.  Simulation  Results  of  the  "AS-IS  "  Process  -  U.S.  Army 

Table  7  presents  a  summary  of  the  data  obtained  from  the  simulation  model. 
Using  the  level  1  diagram  as  the  starting  point,  a  separate  model  was  created  for  the  tasks 
performed  by  the  unit  PAC  and  the  finance  office.  The  tasks  performed  at  DFAS-IN  are 
not  modeled  because  they  represent  the  exit  point  of  the  MPDP. 


Table  7  Simulation  Output  Results  -  U.S.  Army 


Measurement 

“As-Is”  Model  Average  Values 

PAC  Transaction  Processing 

Average  Cycle  Time  per  document 

1.36  hours 

Cost  of  PAC  labor 

$1 15  per  day  /  $3450  per  month 

Productivity  per  PAC  clerk  per  day 

79  per  day 

Utilization  per  PAC  clerk  per  day 

53%  average 

Finance  Transaction  Processing 

Average  Cycle  Time  per  document 

16.36  minutes 

Cost  of  finance  labor 

$281  per  day  /  $8430  per  month 

Productivity  of  the  finance  process 

308  documents  per  coder 

Utilization 

97% 

The  PAC's  tasks  represent  the  first  process  of  the  MPDP  as  shown  in  Figure  4 
above.  By  setting  EXTEND's  modeling  parameters  based  on  the  data  in  Table  4,  we 
determine  the  cycle  time,  productivity,  utilization  measurements,  and  cost.  As  shown  by 
the  graph  in  Figure  6,  cycle  time  and  average  cycle  time  is  plotted  on  the  left  axis,  while 
productivity  and  utilization  is  plotted  on  the  right  axis. 
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Figure  6  Army  PAC  "AS-IS"  Results 


Cycle  time  is  the  measurement  of  the  time  an  item  remains  in  a  process,  either  in 
the  entire  process  or  in  a  specific  part  of  it.  In  this  process  cycle  time  represents  the  actual 
time  it  takes  for  the  PAC  clerk  to  review  documents  received  from  customers  and  prepare 
a  TL.  As  shown  in  the  graph  above  cycle  time  continually  increases.  While  the  average 
cycle  time  is  1.36  hours,  documents  arriving  at  the  end  of  the  day  have  a  cumulative 
cycle  time  of  approximately  2.5  hours.  The  increase  in  cycle  time  for  documents  arriving 
at  the  end  of  the  day  is  attributed  to  the  standard  operating  procedures  enforced  by  the 
finance  office.  PAC  clerks  have  approximately  a  three  hour  window  of  time  in  the 
morning  (0800  until  1100)  to  bring  documents  to  finance  for  processing  that  day. 
Therefore  documents  received  during  the  first  few  hours  of  the  day  are  processed 
immediately.  Documents  received  after  1100  remain  in  the  PAC's  inbox  until  the  next 
morning.  However  it  is  important  to  note  that  PAC  clerks  do  more  than  process  finance 
documents.  Processing  finance  documents  is  only  one  aspect  of  their  job. 

Productivity  is  a  ratio  of  the  outputs  to  the  inputs  that  produce  them.  Productivity 
is  often  based  on  how  many  items  can  be  output  in  a  particular  segment  of  time.  For 
example  if  a  PAC  clerk  processes  1 1  documents  in  one  day  of  labor  (8  hours),  then 
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productivity  is  1 1  per  day.  The  simulation  results  indicate  that  a  PAC  clerk  can  process 
approximately  79  documents  per  day.  However,  documents  dropped  off  at  the  end  of  a 
day  are  not  reviewed  nor  added  to  a  TL  until  the  next  day.  This  standard  operating 
procedure  increases  cycle  time  and  reduces  productivity. 

Utilization  is  the  ratio  of  the  time  busy  processing  compared  to  the  entire  amount 
of  time  available  for  processing.  Utilization  is  calculated  by  multiplying  the  total  time  to 
process  a  document  by  the  number  of  documents  then  dividing  that  number  by  the  time  it 
takes  to  complete  the  entire  process.  For  example,  if  it  takes  44  minutes  to  process  1 1 
documents  the  PACs  utilization  ratio  is  100%  based  on  an  eight  hour  day  ((44*1 1)/480). 
The  simulation  suggests  that  the  PAC  process  is  completely  busy,  during  the  first  3  hours 
of  the  day,  when  performing  the  task  of  reviewing  documents,  preparing  TLs,  and 
carrying  them  to  finance.  [Diamond,  1998] 

The  cost  for  a  PAC  clerk  to  process  documents  received  by  a  customer,  courier 
documents,  and  wait  while  the  finance  receiving  clerk  reviews  the  documents  is 
calculated  using  the  activity  base  costing  (ABC)  functions  in  EXTEND  +  BPR  software. 
ABC  assigns  a  cost  to  the  service  provided  based  on  its  use  by  the  process.  The  analysis 
of  cost  is  used  to  evaluate  the  labor  cost  drivers  and  helps  identify  possible  savings  in  the 
redesigned  alternatives.  Only  the  direct  cost  of  a  clerk's  salary  is  used  to  determine  the 
cost  measurement.  The  cost  per  clerk  is  based  on  the  1999  regular  military  pay 
compensation  for  an  E-4  (pay  rate)  with  three  years  of  service.  The  regular  military  pay 
compensation  includes  basic  pay,  basic  allowance  for  subsistence,  basic  allowance  for 
housing,  as  well  as  the  tax  advantage  from  untaxed  allowances.  The  hourly  rate  in  Table 
4  is  used  as  an  input  parameter  to  calculate  the  cost.  PAC  tasks  are  typically,  but  not  in 
all  cases,  performed  by  a  soldier  of  this  pay  rate.  The  model  suggests  the  cost  for  the 
PAC  process  is  $115  per  day  or  $3446  per  month  (based  on  a  30-day  month).  This 
amount  can  be  multiplied  by  the  total  number  of  PAC  clerks  (33  x  $3446  =  $1 13,718  per 
month)  who  perform  a  similar  process.  One  can  see  that  this  cost  alone  can  be  quite 
substantial  over  the  long  term. 

Next  we  examine  the  "as-is"  measurements  for  the  task  performed  in  the  finance 
office.  A  PAC  clerk  arrives  on  an  average  of  every  15.45  minutes  with  a  batch  of 
documents.  It  takes  the  finance  receiving  clerk  about  5.25  minutes  to  review  a  batch  of 
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documents  and  it  takes  a  coder  an  average  of  17.14  minutes  to  process  a  batch  of  11 
documents.  Cycle  time,  cost,  productivity,  and  utility  are  determined  in  the  same  manner 
described  above  for  the  PAC  process.  The  cycle  time  in  the  finance  process  measures  the 
time  it  takes  for  the  finance  receiving  clerk  to  review  the  documents  plus  the  time  it  takes 
for  the  coders  to  code  the  documents  during  an  eight  hour  day.  Although  reworks  effect 
cycle  time  we  didn't  find  it  significant  enough  to  merit  further  consideration.  The 
simulation  results  indicate  that  the  average  cycle  time  is  approximately  three  hours  per 
batch  (or  seven  minutes  per  document).  This  means  a  single  document  takes  seven 
minutes  to  be  reviewed  by  the  receiving  clerk,  processed  by  a  coder,  and  uploaded  to 
DFAS.  However,  because  the  processing  time  is  slightly  longer  than  the  arrival  interval, 
the  cycle  time  increases  for  documents  that  arrive  at  the  end  of  the  day.  Therefore,  the 
cumulative  cycle  time  for  a  batch  in  the  finance  process  is  approximately  five  hours  (or 
11.5  minutes  per  document).  The  utility  measurement  shows  that  each  coder  is  busy, 
processing  documents  approximately  97%  of  the  time  during  the  workday.  The  cost 
associated  with  performing  this  task  is  $281  per  day  or  $8430  per  month. 

3.  KOPeR  Diagnosis  of  the  "AS-IS"  Process  -  U.S.  Army 

Simulating  the  baseline  process  using  EXTEND  +  BPR  provides  a  graphical 
depiction  of  the  process  for  applying  KOPeR.  The  graphical  depiction  of  the  process  is 
used  to  determine  the  process  measures  shown  in  Table  8.  KOPeR  provides  intangible 
measurements,  which  are  often  ignored  when  using  simulation  models  alone.  The 
measures  obtained  from  KOPeR  provide  baseline  values  essential  for  comparing  and 
evaluating  redesign  alternatives.  The  comparison  allows  one  to  objectively  analyze  real 
improvements  of  the  redesign  alternative  vice  redesign  alternatives  that  merely  represent 
minor  changes  of  the  baseline  process,  with  no  significant  improvement  of  the  process. 
Davenport  concludes  that  there  are  two  primary  reasons  to  measure  the  process  before 
redesigning  it:  1)  problems  must  be  understood  so  that  they  are  not  repeated  and  2) 
accurate  measurement  can  serve  as  a  baseline  for  future  improvements.  [Davenport  and 
Short,  1990] 
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Table  8  Process  Measures  U.S.  Army 


Measures 

Definition 

Calculated 

Measures 

Process  Length 

Number  of  nodes  in  longest  path 

12 

Process  Breadth 

Number  of  distinct  paths 

1 

Process  Depth 

Number  of  process  levels 

1 

Process  Size 

Number  of  nodes  in  process  model 

14 

Process  Feedback 

Number  of  cycles  in  graph 

5 

Parallelism 

Process  Size  divided  by  Length 

1.167 

IT  Support 

Number  of  IT-support  attributes 

7 

IT  Communication 

Number  of  IT-communication 
attributes 

1 

IT  Automation 

Number  of  IT-automation  attributes 

2 

Process  Handoffs 

Process  Handoffs 

5 

Table  9  highlights  the  process  measures  and  pathologies  identified  by  KOPeR.  KOPeR 
measures  suggest  that  the  MPDP  baseline  process  exhibits  five  pathologies  that  can  have 
an  effect  on  the  process  cycle  time  and  cost.  In  this  section  we  examine  the  pathologies 
and  their  consequence  on  process  performance. 


Table  9  KOPeR  Analysis  for  U.S.  Army  ("AS-IS") 


Measures 

Value 

Pathology 

Parallelism 

1.167 

Sequential  Process 

Handoffs  Fraction 

0.357 

Process  Friction 

Feedback  Fraction 

0.357 

Checking  &  Complexity 

IT  Support  (IT-S)  Fraction 

0.5 

Satisfactory 

IT  Communication 

Fraction  (IT-C) 

0.071 

Inadequate  IT  communications 

IT  Automation  (IT- A) 
Fraction 

0.143 

IT  requires  substantial  investment  in 
terms  of  support,  training,  and 
communication 
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KOPeR's  first  measurement  is  parallelism.  The  value  of  1.167  indicates  the 
MPDP  is  nearly  a  completely  sequential  process  (1.00  represents  a  theoretical  minimum 
associated  with  a  perfectly  linear  process).  Sequential  processes  are  widely  noted  by 
reengineering  practitioners  as  problematic  in  terms  of  cycle  time.  This  sequential  process 
is  based  on  the  century-old  notion  of  specialized  personnel  clerks  who  perform  the 
administrative  function  (preparing  the  paper  work)  and  finance  clerks  who  process  the 
pay  transactions  (to  effect  pay).  Sequential  processes  cause  problems,  because  all  the 
data  must  be  available  at  each  step  even  if  it's  not  needed  until  a  later  step.  In  addition, 
Hammer  and  Champy  (1993)  suggest  that  sequential  processes  increase  confusion  -  if  a 
problem  with  a  customer's  requirements  arise  late  in  the  process,  the  customer  (or  his 
documentation)  must  be  referred  back  to  step  one,  requiring  needless  delay  and  rework. 

Next  the  handoff  fraction  measure  of  0.357  indicates  that  the  process  is  highly 
departmentalized,  resulting  in  a  high  level  of  process  friction.  Hammer  and  Champy 
(1993)  suggest  that  handoffs  are  responsible  for  numerous  errors  and  misunderstandings. 
Moreover  the  feedback  fraction  measurement  of  0.357  suggest  excessive  recheck  and 
validation  steps.  Government  bureaucratic  organizations  are  notorious  for 
departmentalizing  work  into  "specialized  foxholes".  Nissen  (1998)  notes  that 
fragmented,  specialized  organizational  approaches  can  lead  to  increased  cycle  time  and 
increased  cost  associated  with  validation  and  rechecks.  Reducing  the  handoff  fraction  can 
positively  impact  cycle  time  and  cost. 

Finally  KOPeR's  measurement  values  for  IT-S,  IT-C,  and  IT-A  reveal  that, 
although  IT  for  support  is  adequate,  IT  for  communication  and  automation  are  not.  With 
detailed  knowledge  of  the  process,  one  can  understand  this  diagnosis  clearly.  This  means 
that  although  adequate  IT  support  is  available,  it  is  not  paying  dividends  in  terms  of 
improvements  in  process  performance.  This  suggests  that  the  process  was  never 
engineered,  and  clearly  illustrates  Hammer's  point  that  IT  alone  will  not  improve  process 
performance.  The  use  of  information  technology  enablers  such  as  form  tools,  word 
processors,  spreadsheet  applications  and  others  must  be  integrated  into  a  comprehensive 
process  redesign  plan.  Conventional  wisdom  in  the  reengineering  profession  suggests 
that  IT  capabilities  should  not  be  considered  until  after  the  process  is  designed.  However, 
Davenport  and  Short  (1990)  suggest  that  an  awareness  of  IT  capabilities  should  influence 
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the  process  design.  "The  role  of  IT  in  a  process  should  be  considered  in  the  early  stages 
of  its  design."  [Davenport  and  Short,  1990] 

The  inadequacies  in  IT-C  are  attributed  to  the  lack  of  electronic  communication 
between  the  PAC  and  the  finance  office.  Furthermore,  lacking  IT-A  to  fully  automate 
simple  manual  routine  tasks  presents  a  significant  shortcoming.  Even  complex  tasks 
requiring  (finance)  experts  can  be  automated  using  expert  systems  and  decision  support 
systems  with  technology  commercially  available  today.  Although  new  technology  may 
require  a  substantial  investment  of  money  and  training  time,  the  long-term  benefits  of 
reduced  cycle  time  and  reduced  cost  may  outweigh  the  initial  investment. 

C.  UNITED  STATES  COAST  GUARD  MILITARY  DOCUMENT  PROCESS 

This  section  describes  the  "as-is"  MPDP  for  a  United  States  Coast  Guard 
Personnel  Servicing  Records  Unit  (PERSRU),  which  provides  pay  support  to  sailors 
located  within  its  Area  of  Responsibility  (AOR).  Although  the  process  description  is  that 
of  a  particular  PERSRU,  it  is  typical  to  most  PERSRUs  that  perform  a  similar  mission. 

1.  "AS-IS"  Process  Description 

The  CG's  MPDP  is  very  similar  to  the  Army's  linear  batch  process.  Documents  are 
created  by  sailors,  given  to  the  unit  yeoman  who  couriers  the  documents  to  the  PERSRU 
office  for  processing.  The  PERSRU  electronically  transmits  the  processed  documents  to 
the  Human  Resource  Servicing  Center  (HRSIC),  followed  by  mailing  the  hardcopy  of 
each  document  transmitted.  A  level  1  schema  of  this  process  is  represented  in  Figure  7. 
Figures  8  and  9  show  the  decomposition  of  the  Unit  Yeoman  process  and  the  PERSRU 
process  respectively. 


Figure  7:  US  Coast  Guard  level  1  schema  of  baseline  process 
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The  detailed  process  is  as  follows:  A  sailor  decides  he  wants  to  initiate  a  pay 
change  (Typical  CG  pay  transactions  are  listed  in  Table  6).  The  sailor  reports  to  his 
yeoman  (Coast  Guard's  equivalent  to  a  personnel  and  administrative  clerk  in  the  Army) 
to  retrieve  the  necessary  forms.  In  some  cases  the  form(s)  can  be  downloaded  from  the 
unit  database,  or  the  World  Wide  Web  (WWW).  The  sailor  prepares  the  document  and 
returns  it  to  the  yeoman.  The  yeoman  reviews  the  document  for  completeness  and 
correctness  and  batches  it  with  documents  received  from  other  sailors.  The  yeoman 
couriers  the  batch  of  documents  to  the  PERSRU.  It  should  be  noted  that  documents 
prepared  by  sailors  who  are  at  sea  have  a  significantly  longer  courier  time.  These 
documents  are  transported  by  air  and  typically  take  24  hours  to  reach  the  PERSRU. 

A  PERSRU  yeoman  (similar  to  the  Army's  receiving  clerk)  reviews  the 
documents  submitted  by  the  unit  yeoman  for  completeness  and  correctness. 


Documents  that  are  not  prepared  correctly  are  given  back  to  the  unit  yeoman.  The 
PERSRU  yeoman  takes  the  documents,  sorts  them  by  type,  and  codes  (keypunches) 
them  into  the  computer. 
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Unlike  the  Army,  the  Coast  Guard  does  not  have  yeomen  designated  only  to 
coding  documents.  The  PERSRU  yeoman  who  receives  the  document  also  codes  the 
document.  At  the  end  of  the  day,  the  coder  saves  the  coded  transactions  onto  a  floppy 
diskette,  makes  a  hardcopy  of  the  coded  transactions  and  gives  the  hardcopy,  the  floppy 
diskette,  and  the  document  to  the  reviewer  (similar  to  the  Army's  auditor).  The  reviewer 
ensures  that  the  transactions  are  coded  correctly.  The  reviewer,  who  is  also  the 
uploader,  transmits  the  coded  transactions  to  HRSIC  to  process  against  the  sailor's 
MMPA.  The  decomposition  of  the  PERSRU  office  process  is  shown  in  Figure  9.  This 
process  is  slightly  different  from  the  Army,  where  the  auditor  and  uploader  are  different 
people.  If  the  transactions  are  without  error,  the  changes  are  processed  against  the 
sailor's  MMPA  at  HRSIC.  If  the  uploaded  transactions  have  any  errors,  they  are 
rejected,  reworked  and  resubmitted. 


Figure  9  PERSRU  Office  Process  (decomposition) 


2.  Simulation  Results  of  the  "AS-IS"  Process  -  U.S.  Coast  Guard 

The  authors  simulate  the  “as-is”  process  of  the  CG’s  MPDP  system  using 
EXTEND  +  BPR.  Once  the  model  is  created,  a  simulation  run  produces  the  outputs  for 
the  CG’s  yeoman  transaction  process  and  PERSRU's  transaction  process  shown  in  Table 
10. 
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Table  10  Simulation  Output  Results  -  U.S.  Coast  Guard 


Measurement 

“As-Is”  Model  Average  Values 

Unit  Yeoman  Transaction  Time 

Average  Cycle  Time  per  document 

2.19  hours 

Cost  per  unit  Yeoman 

$50  per  day /  $1500  per  month 

Productivity  of  Yeoman  per  day 

7  documents 

Utilization 

60% 

PERSRU  Transaction  Processing 

Average  cycle  Time  per  document 

17.25  min 

Cost  of  PERSRU  Yeoman 

$164  per  day /  $4920  per  month 

Productivity  of  PERSRU  Yeoman  Per  day 

115  documents 

Utilization 

98% 

The  unit  yeoman  transaction  process  represents  the  beginning  of  the  MPDP  and  is 
the  starting  point  as  depicted  in  above  in  Figure  7.  In  order  to  get  measurements  of 
important  factors  like  cycle  time,  productivity,  and  utilization  cost  reflecting  the  day  to 
day  transactions  and  processes,  we  use  the  input  variables  in  Table  5.  Cycle  time, 
productivity,  utilization,  and  cost  are  defined  in  Chapter  III,  Section  B,  Subsection  2. 

One  of  the  most  important  factors  to  measure  and  improve  in  BPR  is  cycle  time. 
For  the  unit  yeoman,  cycle  time  represents  the  time  it  takes  a  unit  yeoman  to  receive  a 
pay  document  from  a  sailor,  review  the  document  for  correctness,  prepare  a  transmittal 
letter,  and  transport  the  document  to  the  PERSRU.  Figure  10  shows  that  average  cycle 
time  is  1.89  hours  and  accumulative  cycle  time  is  2.82  hours.  Documents  placed  in  the 
unit  yeoman's  in-box  near  the  end  of  the  day  are  not  processed  until  the  next  morning. 
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Figure  10  U.S.  Coast  Guards  Unit  Yeoman  "AS-IS"  Results 
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Contributing  to  the  high  cycle  time  is  the  standard  operating  procedures  followed  by  the 
yeomen.  These  procedures  require  unit  yeoman  to  submit  documents  to  the  PERSRU 
between  0800  and  1200  to  process  for  the  current  day.  With  only  a  four  hour  window  to 
process  documents  the  unit  yeoman  normally  concentrates  on  finance  tasks  at  the 
beginning  of  the  day.  If  documents  are  not  submitted  in  the  allotted  window  they  are  held 
by  the  unit  yeoman  and  submitted  the  next  business  day.  It  is  important  to  realize  that  the 
MPDP  process  examines  only  one  of  many  tasks  unit  yeomen  and  PERSRU  yeomen  are 
responsible  for. 

Productivity  for  an  eight-hour  workday  is  five  pay  documents  per  day.  In  this  case  the 
unit  yeoman  receives  five  pay-related  documents  a  day.  The  yeoman’s  utilization 
measurement,  based  on  an  eight  hour  workday  says  that  40%  of  the  unit  yeoman's  time  is 
spent  doing  other  jobs,  while  60%  of  his  time  is  spent  processing  pay  documents. 

The  cost  for  a  unit  yeoman  to  review  five  pay  documents,  write  a  transmittal 
letter,  transport  the  TL  to  the  PERSRU,  and  wait  for  the  PERSRU  yeoman  to  review  the 
TL.  ABC  is  used  to  assign  a  cost  to  the  service  that  the  yeoman  provides.  The  unit 
yeoman  who  completes  these  tasks  normally  holds  a  pay  rate  of  E-5  with  five  years  of 
service.  The  1999  military  pay  table  was  used  to  calculate  the  hourly  basic  pay  rate  of  E- 
5  with  five  years  of  service.  The  model  shows  a  cost  of  $50.00  per  day  or  $1500  a  month 
for  the  unit  yeoman  process.  The  cost  can  be  further  aggregated  for  the  number  of  unit 
yeoman  typically  serviced  by  a  PERSRU. 

The  next  process  transaction  we  examine  from  the  level  1  schema  in  Figure  7  is 
the  PERSRU  process.  Documents  arrive  every  18  minutes  at  the  PERSRU.  The 
PERSRU  yeoman  takes  10  minutes  to  review  a  TL  and  clear  up  any  obvious  mistakes. 
On  average  a  TL  contains  a  batch  of  five  documents.  It  takes  about  20  minutes  for  a 
PERSRU  yeoman  to  code  a  batch  of  documents  and  for  the  auditor  to  review  coded 
documents  and  upload  them.  Cost,  productivity,  and  utilization  are  determined  using  the 
same  technique  for  the  unit  yeoman.  Average  cycle  time  is  approximately  3.5  hours  (or 
about  43  minutes  per  batch).  The  simulation  suggests  that  the  PERSRU  processes  23 
batches  of  pay  related  documents  per  day.  The  utilization  measurement  shows  the 
PERSRU  is  fully  utilized.  The  model  indicates  that  98%  of  the  time  is  spent  processing 
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finance  documents  and  2%  doing  other  jobs.  The  model  suggest  that  the  cost  for  the 
PERSRU  process  is  approximately  $164  or  $4920  per  month. 

3.  KOPeR  Diagnosis  of  the  "AS-IS"  Process  -  U.S.  Coast  Guard 

Simulating  the  baseline  process  using  EXTEND  provides  a  graphical  depiction  of 
the  process  for  applying  KOPeR.  The  graphical  depiction  of  the  process  is  used  to 
determine  the  calculated  measures  shown  in  Table  1 1 . 


Table  1 1  Process  Measures  U.S.  Coast  Guard  ("AS-IS") 


Measure 

Definition 

Calculated  Measures 

Process  Length 

Number  of  nodes  in 
longest  path 

14 

Process  Breadth 

Number  of  distinct  paths 

1 

Process  Depth 

Number  of  process  levels 

1 

Process  Size 

Number  of  nodes  in 
process  model 

14 

Process  Feedback 

Number  of  cycles  in  graph 

5 

Parallelism 

Process  Size  divided  by 
Length 

1.00 

IT  Support 

Number  of  IT-support 
attributes 

7 

IT  Communication 

Number  of  IT- 
communication  attributes 

1 

IT  Automation 

Number  of  IT-automation 
attributes 

2 

Process  Handoffs 

Number  of  inter-role  edges 

5 

The  results  for  the  CG's  MPDP  baseline  obtained  from  KOPeR  are  presented  in 
Table  12.  These  measurements  are  used  to  compare  and  evaluate  redesign  alternatives. 
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Table  12  KOPeR  Analysis  for  US  Coast  Guard  ("AS-IS") 


Measures 

Value 

Pathology 

Parallelism 

1.00 

Sequential  Process 

Handoffs  Fraction 

.357 

Process  Friction 

Feedback  Fraction 

.357 

Checking  &  Complexity 

IT  Support  Fraction 
(IT-S) 

.5 

IT  support  looks  OK 

IT  Communication 
Fraction  (IT-C) 

.071 

Inadequate  IT  communications 

IT  Automation 
Fraction  (IT-A) 

.143 

IT  requires  substantial  support 

The  KOPeR  diagnosis  indicates  that  the  CG's  MPDP  suffers  from  sequential 
process  flow,  process  friction,  checking  and  complexity,  inadequate  IT  communications, 
and  an  absence  of  IT  automation.  These  five  measures  and  pathologies  suggest  serious 
performance  implications. 

First,  KOPeR  evaluates  the  baseline  process  as  being  a  sequential  process.  The 
MPDP  sequential  process  is  based  on  the  CG's  history  of  specialization  training,  which 
focuses  workers  on  one  particular  part  of  the  process.  This  has  cycle  time  implications. 

Second,  we  find  that  there  is  process  friction,  which  is  usually  proportional  to  the 
number  of  associated  handoffs  and  feedback  loops.  We  also  see  that  the  feedback  fraction 
is  high,  which  tells  us  that  information  is  being  transferred  unnecessarily,  and  that 
information  has  to  be  re- validated  while  passing  through  a  process.  Feedback  loops 
normally  increase  the  number  of  handoffs  because  the  node  initiating  the  feedback  must 
be  revisited.  Thus,  one  key  to  reducing  the  number  of  handoffs  is  to  reduce  the  number  of 
feedback  loops. 

Information  technology  support  (IT-S)  is  a  measurement  of  the  number  of  process 
tasks  that  are  supported  by  information  technology.  It  has  been  stated  that  simply 
applying  information  technology  to  a  process  without  reengineering  it  is  just  a  quick  fix. 
KOPeR  diagnoses  the  CG's  MPDP  as  having  adequate  IT-S,  but  these  tools  are  severely 
underused.  More  robust  redesign  transformation  levers  and  enablers  (i.e.,  word 
processors,  spreadsheets,  e-mail  etc.)  can  have  a  direct  effect  on  process  performance. 
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Information  technology  communication  (IT-C)  is  the  number  of  process 
communications  supported  by  information  technology.  KOPeR  diagnosed  this  as 
inadequate  for  the  CG's  MPDP.  There  is  limited  use  of  IT-C  between  the  unit  yeoman, 
PERSRU  yeoman,  and  HRSIC.  Encouraging  more  correspondence  via  email  support  and 
the  electronic  routing  of  documents  should  have  a  positive  effect  on  communication. 

Information  technology  automation  (IT- A)  is  defined  as  the  number  of  process 
tasks  automated  by  information  technology.  KOPeR  diagnoses  the  CG's  MPDP  as 
needing  to  automate  process  activities.  Automation  saves  time  and  money  by  replacing 
human  labor,  but  in  order  for  the  CG  to  implement  this  recommendation  a  substantial 
infrastructure  is  first  required,  particularly  in  terms  of  process  support  and 
communication.  The  CG  should  also  look  towards  workflow  systems  for  support  and 
communication,  as  well  as  intelligent  agents. 
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IV.  REDESIGN  NEW  PROCESS 


By  the  end  of  the  ”as-is"  analysis  in  Chapter  II,  the  authors  have  a  thorough 
understanding  of  the  MPDP  for  the  Army  and  the  CG.  The  "as-is"  analysis  provides  a 
benchmark  of  the  existing  process  from  which  comparison  of  the  redesign  alternatives  are 
made.  Although  every  process  instance  is  unique  in  some  respect,  military  processes  in 
particular  share  great  similarities  across  various  units,  commands,  services,  and  even 
allied  nations.  Such  similarities  facilitate  the  wide  spread  practice  of  rotating  officers  to 
new  units  and  assignments  every  few  years.  This  serves  to  leverage  the  power  of  process 
redesign  in  the  military  where  service  processes  are  highly  similar.  What  effects  redesign 
for  one  process  instance  has  excellent  potential  to  also  improve  process  performance 
across  a  myriad  of  other  units,  commands,  and  services.  This  is  certainly  the  case  with 
the  U.S.  Army  and  Coast  Guard.  For  this  reason,  the  redesign  analysis  that  follows 
concentrates  on  a  single,  common  MPDP,  the  results  of  which  generalize  well  across  like 
processes  in  the  Army  and  Coast  Guard.  [DTIC,  1998]  Thus,  because  of  the  similarity  in 
the  Army's  and  CG's  MPDP  and  to  minimize  repetition  and  redundancy,  we  develop 
redesign  alternatives  which  can  easily  be  applied  to  either  organization,  while 
highlighting  significant  differences  in  the  application  of  redesign  alternatives  to  the 
different  services. 

Continuing  with  the  methodology  in  Chapter  II,  the  authors  identify 
transformation  enablers  and  develop  redesign  alternatives.  Our  goal  is  to  develop 
redesign  alternatives  capable  of  yielding  order  of  magnitude  improvements  in  process 
performance. 

A.  IDENTIFY  TRANSFORMATIONS  ENABLERS 

We  begin  by  identifying  and  defining  transformation  enablers.  Table  13  presents 
the  class-level  taxonomy  of  redesign  transformations,  on  which  we  elaborate  in  this 
section.  [Nissen,  1998]  The  first  five  transformations  are  explicitly  addressed  through 
redesign  analysis.  The  latter  two  -  inter-organizational  alliance  and  management  and 
culture  -  are  not  considered  in  present  redesign  analysis.  We  feel  that  by  eliminating  the 
middlemen  there  is  little  need  for  traditional  inter-organizational  coordination.  The  need 
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to  reduce  cost  also  poses  a  need  to  reduce  coordination  (cost).  The  infusion  of 
technology  in  the  three  alternatives  seeks  to  solve  both  problems.  While  we  feel  that 
finance  management  and  cultural  change  is  necessary  to  the  initial  success  of  each 
alternative,  it  is  not  essential  to  the  long  term  success.  The  alternatives  we  present 
eliminate  the  leadership  role  and  replace  it  with  technology.  Initially  management  will 
play  a  key  role  in  obsolescing  their  job  as  the  MPDP  transitions  from  manual  to  virtual. 
New  decisions  will  focus  on  technological  matters  and  require  fewer  managers  in  the 
loop,  as  oppose  to  traditional  people  matters. 


Table  13  Taxonomy  of  Redesign  Transformations 


Transformation  Class 

Sample  Instance  (Object) 

Workflow  reconfiguration 

Process  de-linearization 

Information  technology 

Shared  database  system 

Organizational  design 

Case  manager 

Information  availability 

Informate  agent 

Human  resource 

Team-based  compensation 

*  Inter-organizational  alliance 

Supplier-manager  inventory 

*  Management  &  culture 

Employee  stock  ownership 

*  Transformation  classes  considered  but  not  used  during  the  redesign  step 


Workflow  reconfiguration  examines  how  the  steps  in  a  process  are  performed,  but 
not  who  performs  the  activities.  "Process  de-linearization  -  rearranging  serial  process 
activities  to  be  performed  more  in  parallel  -  represents  one  example  of  a  transformation 
enabler  from  this  class."  [Nissen,  1998]  An  important  point  to  make  about  workflow  is 
that  work  should  be  performed  where  it  makes  the  most  sense.  In  the  redesign 
alternatives  for  the  MPDP  we  suggest  that  it  makes  sense  to  process  the  work  associated 
with  a  pay  transaction  at  the  level  of  the  customer.  De-linearization  is  not  an  option  for 
the  MPDP  however,  because  the  tasks  in  the  process  are  sequentially  dependent; 
therefore  they  can  not  be  performed  in  parallel. 

Information  technology  (IT)  is  used  to  alleviate  mundane  manual  tasks,  increase 
workflow  efficiencies  and  communication  across  functional  areas  while  improving 
process  performance.  Paper-based  forms  of  communication  are  examined  in  the  MPDP  to 
reduce  the  number  of  people-to-people  or  paper-to-people  transactions  necessary  to 
provide  pay  service.  Some  examples  of  information  technology  are  shared  database 
systems,  workflow  tools,  networks  (Internet  and  Intranets),  and  e-mail.  IT  has  great 
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potential  to  alter  business  processes  and  create  new  value-added  services.  [Grenier  and 
Metes,  1995]  However,  incorrect  application  of  IT  may  only  result  in  process 
improvements  rather  than  breakthroughs.  Take,  for  example,  the  automation  of 
document  routing  in  the  travel  approval  and  reimbursement  process.  Instead  of  a  paper 
being  physically  sent  from  approval  station  to  approval  station,  electronic  forms  are 
routed  through  the  network.  This  application  of  IT  simply  automates  existing  processes 
instead  of  seeking  to  reengineer  the  process  and  take  full  advantage  of  the  technology.  In 
this  case,  why  route  the  document  at  all.  Why  not  electronically  post  the  document  to  an 
approval  room  (similar  to  a  chat  room),  for  that  particular  document,  where  authorized 
approvers  can  check  and  handle  the  approval  process.  In  redesigning  the  MPDP, 
workflow  tools  are  coupled  with  Internet  technology  to  develop  alternatives  and  realize 
breakthrough  performance  improvements. 

Organizational  design  looks  at  changing  the  organization's  structure  (e.g.,  from 
hierarchical  to  flat).  Case  teams  are  used  as  enablers  to  integrate  tasks  between 
functional  departments.  Case  teams  can  help  reduce  cycle  time  and  cost  by  eliminating 
unnecessary  handoffs.  They  also  enhance  job  enrichment  by  increasing  team  member 
responsibility  and  allowing  the  team  to  take  full  responsibility  of  process  tasks  from  start 
to  finish.  Case  teams  also  allow  for  the  sharing  of  knowledge  and  information  comprising 
the  team  with  at  least  one  very  experienced  member.  Non-value  added  activities  that 
create  delay,  excess,  or  redundancy  in  a  process  should  be  eliminated.  Activity  titles  with 
the  following  words  usually  reveal  non-value-added  activities:  move,  wait,  check,  review, 
verify,  store,  inspect,  rework,  record,  and  approve.  Any  activity  that  the  customer  does 
not  value  should  be  significantly  reduced  or  eliminated.  [Grenier  and  Metes,  1995] 

As  an  instance  of  the  organizational  design  class  we  add  an  enabler  called 
disintermediation.  In  the  redesign  alternatives  we  apply  disintermediation  as  an  enabler. 
Ted  Lewis  writes  in  his  book,  The  Friction  Free  Economy,  that  value  can  be  added  to  a 
service  by  flattening  the  value  chain.  "A  value  chain  is  flattened  by  elimination  of  links. 
In  the  terminology  of  the  old  industrial  economy,  these  links  are  called  middlemen. " 
[Lewis,  p.  132-133]  Lewis  says  that  the  elimination  of  links  may  be  as  subtle  as 
accessing  your  bank  account  from  your  PC  at  home,  thereby  reducing  the  need  for  bank 
tellers  and  possibly  banks.  The  concept  of  disintermediation  says  that  by  replacing  the 
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middlemen  with  technology  one  can  add  value  to  the  service  while  reducing  cost  and 
cycle  time.  In  the  MPDP  the  middlemen  are  considered  the  PAC  functions  and  the 
finance  office  functions. 

Information  availability  examines  the  type,  amount  and  accuracy  of  information 
available  for  use  by  the  people  who  need  it.  There  is  a  vast  amount  of  information 
contained  in  finance  regulations.  This  information  governs  the  use,  preparation,  and 
routing  of  finance  documents.  An  enabler  that  would  allow  one  to  take  advantage  of  this 
information  is  a  decision  support  system  (DSS).  A  DSS  is  capable  of  distilling  vast 
amounts  of  data  into  information  for  customers  who  require  help  and  answers  to  common 
finance  questions.  Technology  can  impact  this  transformation  class  by  providing  perfect 
information  to  the  customer.  Lewis  (1997)  suggests  that  middlemen  exist  because  of 
imperfect  information.  Providing  information  directly  to  the  customer  early  in  the 
process,  supported  by  an  automated  DSS,  one  could  possibly  prevent  unnecessary  rework 
and  feedback.  Customers  can  have  immediate  access  to  needed  information,  without 
sifting  through  large  regulations  previously  constrained  to  the  domain  of  PAC  clerks,  unit 
yeomen,  finance  clerks,  and  PERSRU  yeomen. 

Human  Resource  examines  how  the  new  skills  are  needed  to  prepare  for  the  new 
jobs  created  as  a  function  of  the  redesign  project.  The  MPDP  redesign  project  requires  a 
close  examination  of  the  core  competencies  needed  by  finance  officers  and  enlisted 
personnel.  We  suggest  that  finance  core  competencies  must  change  to  support  the 
technical  environment  needed  to  reduce  cycle  time  and  cost.  Tracking  well-defined 
performance  measures  will  allow  managers  the  ability  to  quantify  results  and 
compensation. 

B.  GENERATE  AND  ANALYZE  REDESIGN  ALTERNATIVES 

Now  that  transformation  enablers  are  identified,  we  apply  them  to  each  redesign 
alternative.  The  three  redesign  alternatives  consider  a  near-term  (Alternative  One),  mid¬ 
term  (Alternative  Two),  and  far-term  (Alternative  Three)  solution.  The  redesign 
alternatives  are  analyzed  using  KOPeR,  then  simulated  using  EXTEND  +  BPR,  and 
relative  performance  comparisons  are  made  against  the  baseline  model. 
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The  near-term  solution  focuses  on  a  redesign  alternative,  which  can  yield 
dramatic  increases  in  process  performance  while  requiring  minimal  organizational 
disruption.  This  model  includes  proven  technological  capabilities  currently  available 
from  commercial  sources  and  easily  implemented.  Although  the  near-term  solution  can 
be  implemented  with  minimal  effort,  it  is  still  radically  different  than  the  baseline  model. 
The  mid-term  solution  incorporates  the  near-term  enhancements  while  increasing  the  use 
of  technology  that  include  Intranet  technologies  and  advanced  workflow  tools.  This 
alternative  may  require  a  paradigm  shift  in  the  way  the  services  view  the  role  of  the 
finance  and  the  PERSRU  office.  Finally,  the  far-term  solution  incorporates  alternative 
one  and  two  while  taking  full  advantage  of  Internet,  workflow,  and  distributed  database 
technology.  Our  redesign  solutions  are  based  on  the  notion  that  by  eliminating  the 
middlemen  and  "squeezing  out  inefficiencies",  in  Figure  1 1,  as  a  part  of  a  comprehensive 
redesign  approach  we  can  reduce  cycle  time,  cost,  and  increase  customer  service.  [Lewis, 
p.  133] 


Figure  11.  High-level  representation  of  Baseline  process 


To  better  illustrate  the  three  redesign  alternatives,  we  use  rich  text  pictures  as 
presented  in  Figures  13,  14,  and  15.  The  alternatives  are  discussed  in  the  context  of  how 
each  redesign  alternative  uses  the  transformation  enablers  (e.g.,  workflow,  technology, 
and  organizational  change)  described  in  Section  A  above  to  improve  the  MPDP  process. 
To  reduce  redundancy,  we  only  highlight  differences  between  each  alternative.  We  begin 
by  discussing  Alternative  One  and  outline  how  it  differs  from  the  baseline.  Then  we 
discuss  Alternative  Two  and  describe  how  it  improves  on  Alternative  One,  which  is 
followed  by  a  discussion  of  Alternative  Three  improvements.  Finally  we  summarize  the 
redesign  enhancements  for  all  three  alternatives. 
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1.  Alternative  One 

Alternative  One,  Figure  13,  takes  advantage  of  the  following  transformation 
enablers:  workflow,  technology,  organizational  and  information  availability.  Workflow  is 
used  to  accomplish  each  task  where  it  makes  the  most  sense,  at  the  customer  level.  Three 
basic  technologies  are  used  to  accomplish  this:  knowledge-based  DSS,  electronic  forms, 
and  email.  Using  a  knowledge-based  DSS  the  customer  answers  questions  pertaining  to 
the  potential  transaction.  After  answering  the  questions  the  customer  is  presented  with  the 
proper  electronic  form  for  the  transaction.  Electronic  forms,  such  as  the  ones  created  by  a 
company  called  FedSoft  Corp,  based  in  Fairfax,  Virginia,  are  e-mailed  to  the  finance 
office  for  processing.  In  the  baseline  process  the  PAC  accomplished  the  tasks  of 
determining  the  customer's  needs,  assisting  with  form  preparation,  and  submitting  forms 
to  finance.  The  use  of  workflow  and  technology  enablers  eliminates  the  need  for  the 
PAC. 

In  Alternative  One,  to  facilitate  the  process  in  the  finance  office,  organizational 
enablers  are  used  to  create  two  person  case  teams.  Each  team  has  responsibility  for 
servicing  specific  units.  Each  member  on  the  team  is  a  trained  auditor  and  is  empowered 
with  the  capability  to  upload  documents  to  DFAS-IN.  By  aligning  each  team  with 
specific  units  and  providing  upload  capabilities  to  each  member,  one  creates  job 
enrichment  and  job  satisfaction.  Teams  receive  electronic  documents  e-mailed  from  their 
customers,  code  the  transactions,  and  upload  the  information  to  DFAS-IN.  Tracking 
measurement  metrics  such  as  accuracy  statistics  on  each  team  can  provide  information  to 
managers  about  a  team's  effectiveness  and  other  statistics  may  help  to  identify  training 
needs.  Case  teams  provide  task  ownership,  attach  responsibility  to  task  accomplishment, 
and  allow  members  to  see  the  job  through  from  start  to  finish.  This  also  creates  a  sense 
of  mission  accomplishment.  Although  the  use  of  technology  in  this  alternative  is  limited, 
the  process  is  very  different  from  the  baseline.  Case  teams  can  have  positive  performance 
effects  in  terms  of  cycle  time  (and  often  cost),  as  a  single  case  team  eliminates  the  need 
for  handoffs  and  inter-departmental  coordination.  [Nissen,  1995]  Remember  in  the 
baseline  there  are  three  coders,  an  auditor,  and  an  uploader.  Only  the  uploader  has  the 
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capability  to  upload  documents  to  finance.  Also  in  the  baseline  coders  coded  any 
documents  available.  There  is  no  sense  of  ownership  of  the  product  or  task.  Through  the 
use  of  the  enablers  described  above  the  customer  now  has  good  information  early  in  the 
process  and  can  perform  the  transaction  himself  without  assistance  from  the  PAC.  This 
alternative  is  the  first  step  at  eliminating  the  middlemen  (PAC  and*  Finance). 

2.  Alternative  Two 

Alternative  Two,  Figure  14,  uses  the  same  enablers  as  one,  but  enhancement  in 
technological  enablers  provides  more  functionality  for  the  customer  and  eliminates  the 
finance  office  case  teams  in  Alternative  One.  Alternative  Two  enhances  workflow  by 
using  an  Intranet  and  e-forms  with  a  front-end  web  page  and  a  backend  (local)  database 
located  at  the  finance  office.  The  web  page  incorporates  the  DSS  used  in  Alternative  One 
to  help  the  customer  determine  the  correct  form  for  a  particular  transaction.  The  local 
database  contains  a  copy  of  the  soldier's  MMPA.  Authentication,  encryption,  and  digital 
signatures  are  used  when  customers  access  the  web  page  and  log  in  to  conduct  a 
transaction.  This  local  database  provides  each  customer  with  the  ability  to  access  his 
account  in  near  real  time.  When  he  wants  to  conduct  a  transaction,  he  answers  a  series  of 
questions,  an  e-form  is  displayed  and  only  the  fields  pertaining  to  the  transaction  are 
accessible.  When  the  customer  submits  the  form  the  data  are  compared  against  his 
account  on  the  local  database.  If  the  transaction  is  valid,  a  transaction  confirmation  is 
returned  to  the  customer.  If  the  transaction  is  not  valid,  the  system  returns  a  narrative 
reason  why  the  transaction  could  not  be  processed  at  this  time.  Alternative  Two,  unlike 
Alternative  One,  prevents  a  customer  from  submitting  transactions  that  are  not  valid.  In 
Alternative  One  the  customer  could  submit  a  transaction,  and  allotment  for  example,  that 
was  invalid.  An  example  of  an  invalid  allotment  transaction  would  be  a  transaction  to 
start  a  duplicate  allotment.  In  Alternative  One  this  could  happen  and  not  be  noticed  until 
it  was  rejected  by  DFAS-IN.  In  Alternative  Two  the  use  of  a  local  database  provides  the 
soldier  with  near  real  time  feedback. 

In  Alternative  Two  an  organizational  change  at  the  finance  office  eliminates  case 
teams  and  replaces  them  with  a  front-end  finance  web  page,  local  database,  and  a  system 
administrator.  Currently  there  are  many  commercial  off  the  shelf  software  and  hardware 
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products  which  can  be  used  to  create  an  environment  for  Alternative  Two.  Software 
tools  such  as  Cold  Fusion  can  be  used  to  create  dynamic  web  pages  and  integrate  a 
relational  backend  database.  There  are  also  enterprise  resource  solutions,  developed  by  a 
company  called  Systems,  Applications,  and  Products  in  Data  Processing  (SAP)  for 
example,  that  focus  on  process  integration  and  functional  area  integration.  These 
products  enhance  the  capability  for  single  source  data  input.  The  transaction  information 
entered  by  the  customer  at  the  web  site  never  has  to  be  entered  again.  It  is  converted  into 
the  proper  format  and  processed  against  the  local  database.  The  system  administrator 
uploads  transactions  and  updates  local  databases  nightly.  The  use  of  a  local  database 
allows  the  customer  the  ability  to  query  his  transaction  history  and  account  status,  having 
almost  perfect  information  prior  to  submitting  a  transaction.  The  customers,  during  in 
processing,  would  only  report  to  finance  to  receive  their  user  names  and  passwords.  This 
alternative  brings  use  another  step  closer  to  completely  eliminating  the  need  for  the 
middlemen. 

3.  Alternative  Three 

Alternative  Three,  Figure  15,  folly  incorporates  the  Internet  and  distributed 
database  technologies  to  create  a  virtual  finance  office.  This  virtual  finance  office  uses 
web-based  tools  to  process  transactions  for  customers  in  near  real  time.  This  alternative 
requires  DFAS-IN  to  maintain  a  web  page  accessible  by  customers  from  anywhere  in  the 
world  any  time  of  the  day.  In  Alternative  Three  customers  receive  immediate 
notification  when  the  transaction  is  processed.  In  this  alternative  customers  access  a  web 
page  with  user  friendly  menus.  Customers  can  check  on  the  status  of  their  accounts, 
retrieve  and  print  Leave  and  Earning  Statements  (LES),  and  review  their  transaction 
history  files.  In  the  baseline,  Alternative  One,  and  Alternative  Two,  LESs  are  prepared  at 
DFAS-IN,  mailed  to  the  finance  office  and  distributed  to  each  unit.  For  a  customer  to  get 
pay  information  prior  to  the  end  of  the  month  requires  a  special  request.  Using  e-forms, 
the  Internet,  enterprise  resource  planning  software  solutions,  and  distributed  database 
technology,  the  information  input  by  the  customer  goes  directly  to  DFAS-IN  without 
human  intervention,  handoff,  feedback  loops,  or  human  friction.  This  alternative  results 
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in  a  new  paradigm  where  the  middlemen  are  replaced  by  technology.  Figure  12 
illustrates  the  new  paradigm. 


Figure  12.  High-level  Model  of  Redesign  Alternatives  (New  Paradigm) 


4.  System  Security  Issue 

Technology  enablers  are  the  centerpiece  of  redesign  Alternatives  Two,  and  Three. 
While  technological  enhancement  may  eliminate  the  middleman  and  add  value  to  the 
customer,  they  also  add  risk  to  the  process.  Sending  privacy  information  such  as  names 
with  social  security  numbers  over  electronic  medium  has  always  been  a  concern  for  the 
military  services.  Incorporating  electronic  forms  into  workflow  will  require  the  use  of 
digital  signatures  and  data  encryption  to  ensure  privacy,  integrity,  and  authentication  of 
the  customer.  The  Department  of  Defense  (DOD)  and  Netscape  are  addressing  security 
concerns.  Last  year  DOD  signed  a  deal  with  Netscape  to  provide  a  public  key 
infrastructure.  Because  Netscape  clients  and  servers  support  both  FIPS-1  and 
FORTEZZA  security  standards,  new  DOD  systems  will  be  able  to  secure  various  levels 
of  information,  from  basic  e-mail  messages  to  top-secret  information  on  troop  movement 
and  battle  strategy.  [Hayes,  1998]  Security  technology  must  be  incorporated  into  each 
redesign  alternative. 

5.  Summary 

Alternative  One  presents  significant  enhancements  over  the  baseline  using  several 
transformation  enablers.  Alternatives  Two  and  Three  eliminate  the  PAC  and  finance 
office  tasks.  Using  the  concept  of  disintermediation  these  alternatives  eliminate  the 
middlemen  using  technology  to  accomplish  tasks  previously  done  by  humans.  Expert 
systems  and  decision  support  systems  replace  expert  people.  The  tasks  preformed  by  the 
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PAC  (determining  need,  selecting  document(s),  and  assisting  with  document  preparation) 
and  the  finance  office  (coding  documents)  is  done  at  the  customer  level  assisted  by 
technology  (soldier  or  sailor).  The  concept  is  no  different  than  on-line  banking.  Thus, 
moving  the  task  closer  to  the  source  (the  customer)  will  shorten  the  value  chain,  reducing 
cost  and  cycle  time  while  improving  the  customer  service. 

Time  consuming  and  costly  reworks  for  incorrect  documents  will  become 
obsolete.  Smart  (expert)  systems  will  ensure  that  documents  are  correct  or  they  will  not 
get  submitted.  Replacing  the  middlemen  in  this  process  is  simplified  by  the  standardized 
way  the  MPDP  is  designed.  There  are  very  few  complex  decisions  made  in  this  process. 
Expert  information  (rules  for  entitlements  and  preparation  of  forms)  is  found  in  the 
Department  of  Defense  Financial  Management  Regulation  (DODFMR).  The  DSS  in  each 
alternative  captures  complex  human  knowledge  about  finance  topics  on  a  computer.  The 
essence  is  in  the  interrelationship  among  the  various  items  of  information  in  so-called 
knowledge  bases  or  finance  manuals.  This  relationship  is  expressed  as  "if.. .then..."  type 
of  rules.  The  logical  manipulation  of  logical  operations  is  a  somewhat  primitive  imitation 
of  human  thought  processes,  but  it  is  well  established  and  effective  nonetheless. 

By  removing  non-value  added  tasks  one  can  eliminate  the  costs  incurred  from 
those  tasks.  As  Lewis  (1998)  describes  in  the  Friction  Free  Economy,  by  infusing 
technology  and  eliminating  the  middlemen  one  can  increase  the  value  added  to  the 
customer  by  making  pay  transactions  more  timely  and  less  costly.  Once 
disintermediation  is  applied,  shortening  the  value  chain  is  a  natural  outgrowth.  The 
hierarchical  structure  supporting  this  process  is  reduced  to  the  customer  (soldier  or  sailor) 
and  the  supplier  (DFAS  or  HRSIC)  as  shown  in  Figure  15.  Disintermediation 
incorporated  with  a  comprehensive  approach  to  process  redesign  can  dramatically 
improve  process  performance  by  eliminating  non-value  added  tasks. 
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Figure  13.  Rich  Text  Picture  Alternative  One 
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Figure  14.  Rich  Text  Picture  Alternative  Two 


54 


55 


C.  SIMULATION  RESULTS  OF  REDESIGN  ALTERNATIVES 

When  simulating  the  redesign  alternatives  we  use  the  input  values  from  Table  4. 
Each  alternative  assumes  some  delays,  not  calculated  in  this  thesis,  associated  with 
network  throughput  and  computer  processing.  We  assume  these  delays  are  negligible 
when  the  network  is  operating  properly  and  that  they  will  not  affect  cycle  time.  Results 
are  summarized  in  table  14. 

The  simulation  results  for  Alternative  One  indicate  an  average  cycle  of  nine 
minutes  per  document.  Recall  that  the  cycle  time  per  document  in  the  baseline  process  is 
1.36  hours  for  the  PAC.  Using  electronic  documents  and  email  in  Alternative  One  we 
have  eliminated  the  PAC  function  and  effectively  eliminated  the  associated  cycle  time. 
This  represents  a  100%  improvement  over  the  PAC  process  in  each  redesign  alternative. 
The  average  cycle  time  for  Alternative  Two  and  Three  can  not  be  adequately  measured, 
because  it  is  dependent  on  the  communication  architecture  and  the  latency  associated 
with  network  throughput.  But  without  human  (middlemen)  intervention,  cycle  time  for 
this  process  step  effectively  approaches  zero.  Recall  the  baseline  model  of  both  the 
Army  and  the  CG  where  the  PAC  clerk/unit  yeoman  only  had  a  three  or  four  hour 
window  in  the  morning  to  get  documents  to  finance  to  be  processed  for  that  business  day. 
Each  redesign  alternative  allows  document  submission  on  a  24-hour  basis  by  the 
customer. 

Each  alternative  introduces  technological  enhancements.  Alternative  One's 
introduction  of  workflow  tools  eliminates  the  labor  cost  and  cycle  time  associated  with 
the  PAC  process.  The  cost  of  the  baseline  process  based  on  an  eight-hour  workday  is 
approximately  $1 1,880  per  month.  This  amount  is  the  aggregate  cost  of  the  PAC  process 
and  the  finance  process  as  shown  in  Table  7,  Chapter  III.  Using  these  values  one  can  see 
that  Alternative  One  yields  47%  savings  in  labor  cost  over  the  baseline. 

In  Alternative  Two  we  calculate  labor  cost  for  a  system  administrator  to  maintain 
a  local  database  and  a  web  page  for  the  finance  office.  We  propose  that  the  administrator 
be  a  military  officer  (or  civilian  equivalent)  with  a  graduate  education,  at  the  rank  of 
0-3/GS-12  (with  6  years)  and  with  some  finance  experience.  Using  the  1999  military 
pay  compensation  table,  we  determine  a  cost  of  approximately  $4,577  per  month  for  an 
administrator.  In  Alternative  Three  we  add  the  cost  of  one  web  master  to  manage  the 
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web  page  at  DFAS-IN.  DFAS-IN  currently  has  system  administrators  who  manage  the 
database  containing  the  MMPAs.  We  assume  based  on  current  service  (DFAS 
Homepage)  provided  by  DFAS  that  the  communication  and  software  infrastructure  to 
facilitate  this  redesign  alternative  is  minimal.  Alternative  Two  and  Three  eliminate  the 
cost  associated  with  labor  for  the  PAC  process  and  the  finance  process  by  replacing  them 
(the  middlemen)  with  technology  and  can  potentially  yield  a  61%  savings  over  the 
baseline. 

Although  the  initial  overhead  cost  associated  with  software  and  hardware 
upgrades  and  training  can  be  substantial,  the  automation  infrastructure  in  most  finance 
offices  can  facilitate  easy  migration  from  current  systems  to  web  based  distributed 
network  technology  with  minimal  upgrades.  This  comparison  illustrates  that  eliminating 
the  middlemen  in  MPDP  will  result  in  significant  savings  in  the  cost  of  direct  labor  while 
decreasing  document  cycle  time  and  increasing  customer  satisfaction. 


Table  14  Extend  Output  Results  of  Redesign  Alternatives 


Measures 

Baseline 

Alternative 

One 

Alternative 

Two 

Alternative 

Three 

Average  Cycle  Time 
per  document 

lhr  42min 

9  minutes 

Effectively  zero 

Effectively  zero 

Cost  of  labor  per 
month 

$11,880 

$6263 

$4,577  * 

$4577  * 

*Not  calculated  using  EXTEND 

D.  COMPARE  REDESIGN  ALTERNATIVES  TO  BASELINE  PROCESS 


KOPeR  analyses  of  each  alternative  indicate  a  sequential  process.  However 
workflow  enhancements  have  decreased  the  number  of  handoffs  from  .357  to  0.00 
resulting  in  a  100%  decrease  over  the  baseline,  for  the  three  alternatives.  Alternative  One 
uses  a  simple  DSS,  electronic  forms,  and  e-mail  which  is  practical  and  easily 
implemented.  This  simple  infusion  of  technology  provides  dramatic  improvements  over 
the  baseline  process.  Recall  that  Alternative  One  uses  technology  to  eliminate  the  PAC 
function,  but  maintains  the  finance  office  and  reorganizes  it  into  case  teams.  Alternative 
One  does  not  allow  the  customer  to  verify  the  validity  of  his  transaction  prior  to 
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submission.  Therefore  it  is  possible  that  the  case  team  may  have  to  send  the  document 
back  to  the  customer  because  the  transaction  requested  is  invalid  (i.e.,  trying  to  stop  and 
allotment  that  doesn't  exist).  Consequently  there  is  a  limited  decrease  of  7%  in  the 
feedback  fraction.  This  is  remedied  in  Alternative  Two  and  Three  by  providing  web 
interface  to  a  local  database  or  directly  to  DFAS-IN  respectively.  These  alternatives 
result  in  a  100%  decrease  in  feedback  friction  over  the  baseline.  This  is  due  in  large  part 
to  the  workflow  tools  and  web  database  interface  technology  that  allows  almost  real  time 
access  to  the  customer's  account.  The  three  alternatives  indicate  a  dramatic  improvement, 
in  information  technology  support,  communication,  and  automation  measures,  over  the 
baseline.  Using  KOPeR,  comparative  measures  for  each  redesign  alternative  are 
presented  in  Table  15. 


Table  15  KOPeR  Com 

parative  Measures 

Measure 

Baseline 

Army 

Alternative 

One 

Alternative 

Two 

Alternative 

Three 

Process  Length 

12 

3 

3 

1 

Process  Handoffs 

5 

0 

0 

0 

Process  Size 

14 

3 

3 

1 

Process  Feedback 

5 

1 

0 

0 

IT  Support 

7 

3 

3 

2 

IT  Communication 

1 

3 

3 

2 

IT  Automation 

2 

3 

3 

2 

Parallelism 

1.00 

1.00 

Handoffs  Fraction 

0.357 

0.0 

0.0 

0.0 

Feedback  Fraction 

0.357 

0.333 

0.0 

0.0 

IT  Support  Fraction 

0.5 

1.00 

1.00 

2.00 

IT  Communication 
Fraction 

0.071 

1.00 

1.00 

2.00 

IT  Automation 
Fraction 

0.143 

1.00 

1.00 

2.00 
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V. 


SUMMARY,  CONCLUSIONS,  AND  FUTURE  RESEARCH 


A.  SUMMARY 

This  thesis  examined  how  redesigning  the  Army  and  CG's  MPDP  could 
dramatically  improve  cost  and  document  cycle  time.  Chapter  II  presented  background 
information  on  the  evolution  of  the  Military  Pay  System  and  Business  Process 
Reengineering.  Chapter  III  discussed  the  tools  used  to  analyze  and  redesign  the  Military 
Pay  Document  Process.  It  also  provided  simulation  results  as  well  as  KOPeR  diagnoses 
of  the  processes.  Chapter  IV  examined  redesign  alternatives  which  dramatically 
improved  cost  and  cycle  time. 

B.  CONCLUSIONS 

The  KOPeR  analysis  of  the  "as-is"  process  indicates  that  the  MPDP  suffers  from 
major  pathology  faults.  These  pathologies  suggest  serious  performance  implications. 
KOPeR  shows  that  the  baseline  process  is  nearly  sequential,  and  highly  departmentalized 
with  excessive  rechecks.  Measurement  values  for  IT-S,  IT-C,  and  IT-A  revealed  that, 
although  IT-S  is  adequate,  IT-C  and  IT-A  are  not.  This  indicates  that  some  IT  support  is 
available,  but  is  not  paying  dividends  in  terms  of  improved  process  performance. 

Therefore  each  redesign  alternative  presented  in  this  thesis  enhances  these 
shortcomings  by  eliminating  non- value  added  tasks  and  combining  tasks.  Each  suggested 
alternative  yields  an  increase  in  process  performance  over  the  baseline.  Alternative  One 
reduces  labor  cost  by  47%  and  cycle  time  by  90%  (from  1.5  hours  to  9  minutes  per 
document).  Alternatives  Two  and  Three  reduce  labor  cost  by  61%,  as  a  result  of 
eliminating  the  middlemen,  while  effectively  decreasing  the  cycle  time  to  zero  using 
technology  to  shorten  the  value  chain  between  the  customer  (soldiers  or  sailors)  and  the 
supplier  (DFAS  or  HRSIC). 

In  each  redesign  alternative,  IT  does  not  simply  automate  a  flawed  process,  but  it 
is  used  as  an  enabler  to  yield  dramatic  process  performance  improvements  over  the 
baseline  process.  We  took  a  critical  look  at  the  tasks  and  processes  associated  with  the 
MPDP,  and  asked  the  questions  "Why  are  we  doing  it  this  way?"  and  "Can  it  be  done 
better?"  We  concluded  that  by  reengineering  the  MPDP  to  eliminate  the  middlemen  and 
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radically  changing  the  process,  dramatic  improvements  in  process  performance  could  be 
realized.  However,  continued  research  into  technology  cost,  training  cost,  new  manning 
numbers,  and  implementation  planning  is  necessary  to  realize  the  true  benefit  of  these 
redesign  alternatives. 

C.  RECOMMENDATIONS 

The  authors  recommend  that  the  Army  and  Coast  Guard  use  each  alternative  as  a 
building  block,  starting  with  Alternative  One  and  incrementally  increasing  functionality 
to  obtain  the  ultimate  goal  of  the  virtual  finance  office  as  illustrated  in  Chapter  IV,  Figure 
15.  An  incremental  development  process  is  useful  in  systems  engineering  when  all 
requirements  are  not  known  up  front.  Once  Alternative  One  is  deployed,  there  will  be 
suggestions  from  customers  and  new  requires  that  can  improve  the  MPDP  process. 
These  suggestions  can  be  implemented  in  Alternative  Two  and  Three  if  necessary.  The 
incremental  approach  allows  users  and  customers  the  ability  to  take  an  active  role  in  the 
development  of  a  virtual  MPDP. 

The  transition  from  the  current  MPDP  to  Alternative  One  may  be  easier  for  the 
Coast  Guard  than  for  the  Army.  The  Coast  Guard's  finance  office  currently,  as  illustrated 
in  Chapter  IV,  Figure  13,  uses  case  teams  when  processing  documents  at  the  finance 
office.  These  teams  are  already  aligned  with  specific  units.  The  Army,  on  the  other  hand, 
uses  individual  coders  who  have  no  association  or  direct  relationship  with  particular 
units.  Implementing  the  first  alternative  will  require  an  adjustment  period  for  the  Army 
but  can  be  accomplished  with  minimal  impact  on  current  operating  procedure  while 
making  dramatic  improvements  in  process  performance.  Once  Alternative  One  is 
implemented  and  proven  successful,  Alternatives  Two  and  Three  are  simply  functional 
improvements  to  the  first  alternative. 

The  key  to  the  incremental  approach  is  to  establish  a  time  line  for  completing 
each  alternative  upgrade.  Sticking  to  this  time  line  will  require  a  dedicated  team 
throughout  the  planning  and  implementation  phase  of  the  redesign  project. 
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D.  TOPICS  FOR  FUTURE  RESEARCH 


The  information  presented  has  the  potential  to  dramatically  improve  the  MPDP 
using  technology  like  e-forms,  intranets,  distributed  database  technology,  DSS  and  expert 
systems.  The  authors  recommend  four  major  fields  of  study  for  fixture  research  before 
implementing  any  of  the  alternatives  presented  in  Chapter  IV.  These  areas  are  not 
sufficiently  addressed  in  this  thesis  due  to  time  and  scope  limitations. 

1.  Technology  Cost 

Technology  cost  of  the  alternatives  suggested  in  Chapter  IV  is  an  issue  that 
should  be  addressed.  Consider  possible  upgrades  to  the  communication  infrastructure  to 
create  a  larger  bandwidth  capability  for  transmitting  documents  and  information  faster 
and  the  cost  associated  with  software  and  hardware  upgrades.  Addressing  the  cost  for 
hardware  and  software  upgrades,  Gary  Eldridge  states  that  "A  self  examination  should  be 
done  that  looks  at  six  aspects  of  IT  operations:  employees,  internal  operations,  financial, 
innovation  and  learning,  customer  value  and  the  value  of  IT  investment."  It  is  imperative 
that  the  Army  and  Coast  Guard  evaluate  their  current  IT  technology  and  then  research 
what  the  cost  per  unit  for  each  alternative  will  be  to  efficiently  implement  the  Virtual 
Finance  Office. 

2.  Security  Issues 

Security  will  be  a  major  issue  in  the  implementation  of  each  alternative  leading  up 
to  the  Virtual  Finance  Office.  Different  technology  like  data  encryption  and  digital 
signatures  must  be  looked  at  in  an  effort  to  securely  transmit  privacy  information  across 
an  electronic  medium  such  as  the  Internet.  DOD  and  Netscape's  deal  to  provide  a  public 
key  infrastructure,  which  provides  each  military  user  with  a  software  identification  card  - 
complete  with  user  name  and  access  privileges  will  go  a  long  way  in  the  evolution  from 
the  current  MPDP  to  a  virtual  finance  office.  The  result  of  the  security  measures  taken 
by  DOD  and  Netscape  will  allow  users  to  access  a  range  of  enterprise- wide  applications 
and  information  while  eliminating  the  need  for  traditional  DOD  stovepipe 
communication  architecture.  John  Menkart,  the  director  of  federal  sales  for  Netscape 
Government  Group,  said  in  a  recent  article  in  DoDIT  that  "Once  the  system  is  fully  in 
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place  DOD  will  be  able  to  expose  even  the  most  mission  critical  [information]  over  the 
Internet  and  still  assure  that  only  people  that  have  permission  to  access  it  will  be  doing 
so".  [Hayes,  1998]  According  to  Hayes,  the  majority  of  everyday  business  processes  will 
be  automated  and  web-enabled.  These  processes  include  but  are  not  limited  to  product 
ordering  and  delivery,  travel  voucher  settlement,  accounting,  finance  transactions,  and 
official  communications.  The  bottom  line,  says  Menkart,  is  that  the  military  will  be  able 
to  take  the  best  possible  advantage  of  its  system  to  get  and  transmit  information  between 
customers  (soldiers  and  sailors)  and  suppliers  with  an  extremely  high  degree  of  security. 

3.  Training  Cost 

Another  major  stumbling  block  for  projects,  which  involve  new  technology,  is  the 
user's  ability  to  effectively  utilize  the  product.  Infusing  new  technology  will  present  some 
training  challenges.  Soldiers  and  sailors  will  require  training  on  the  use  of  electronic 
forms  and  digital  signatures  while  finance  personnel  will  need  training  on  workflow 
tools,  web  technology,  and  database  maintenance.  The  cost  of  training  and  maintenance 
represents  a  major  part  of  the  life  cycle  cost  of  most  projects.  Therefore  the  use  of 
Commercial  off  the  Shelf  (COTS)  solution  are  critical.  COTS  equipment  can  present 
users  with  common  tools  which  they  currently  use;  therefore  users  require  less  training  to 
become  proficient.  The  use  of  COTS  equipment  allows  one  to  take  advantage  of  the 
research  and  development  dollars  of  the  commercial  world  and  can  help  limit 
maintenance  cost.  If  users  aren't  properly  trained  the  project  is  destined  for  failure. 
Secure  funding  for  adequate  training  is  essential  prior  to  beginning  the  redesign  project. 

4.  New  Manning  Numbers 

The  Army  and  Coast  Guard  will  need  to  examine  new  manning  numbers  for  their 
financial  communities.  Bitzer  suggests  that  improved  worker  productivity,  electronic 
communications,  and  the  automation  of  work  routing,  tracking  and  completion  result  can 
reduced  manpower  requirements.  Extensive  realignment  of  both  organizations  along  with 
the  implementation  of  new  rules  and  regulations  will  be  needed  in  each  redesign  effort. 
Dr.  Sharon  Caudle  notes  that  many  successful  government  organizations  are  adjusting 
their  organizational  structures  and  reporting  relationships  to  better  support  process 


redesign  initiatives.  However,  major  change  will  not  happen  without  top  management 
commitment  and  support.  This  redesign  project  will  require  the  senior  leaders  in  both 
services'  financial  communities  to  become  intimately  involved. 

Currently  the  Army  uses  a  19  plus  person  detachment  to  provide  pay  support  to 
approximately  6000  soldiers.  The  primary  responsibility  of  this  detachment,  as  described 
in  Chapter  III,  is  to  provide  pay  support  using  the  MPDP.  By  implementing  the 
alternative  suggested  in  this  thesis  we  propose  that  a  19  plus  person  detachment  in  its 
current  capacity  is  no  longer  needed.  A  smaller  more  dynamic  organization  can  result 
from  the  suggested  redesign  alternatives.  Such  a  major  paradigm  shift  promises  to  be  a 
bit  of  a  culture  shock  for  people  interested  in  maintaining  their  "rice  bowl".  But  the 
benefits,  in  term  of  cost  saving,  cycle  time,  and  customer  service,  that  come  from 
eliminating  non  value  added  tasks  easily  out  weigh  the  temporary  adjustment  difficulties. 
The  CG's  organizational  structure  is  similar  and  will  face  similar  challenges. 

5.  Implementation  Plan 

A  true  implementation  plan  for  any  of  the  alternatives  listed  in  Chapter  IV  must 
consider  the  technology  cost,  training  cost,  and  manning  changes.  The  authors  visualize 
a  seven-phase  approach  for  the  implementation  of  the  new  MPDP  process.  The  seven 
phases  of  the  implementation  plan  would  include  marketing,  contracting,  prototyping, 
installation,  testing,  training,  and  the  rollout  of  the  new  system.  These  seven  phases,  we 
believe,  are  not  mutually  exclusive  and  some  may  overlap  each  other.  Some  of  these 
phases  will  be  ongoing  throughout  the  project. 

E.  FINAL  THOUGHT 

This  is  a  quote  taken  from  an  executive  summary.  It  expresses  the  need  to 
reengineer  processes  and  eliminate  non-value-added  tasks,  rules,  and  regulations  to 
increase  quality  and  reduce  cost  in  the  federal  government. 

About  10  years  ago,  two  foresters  returned  from  a  hard  day  in  the 
field  to  make  plans  for  the  coming  week.  Searching  for  a  detail  of  agency 
policy,  they  found  themselves  overwhelmed  by  voluminous  editions  of 
policy  manuals,  reports,  and  binders  filled  with  thousands  of  directives. 
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One  forester  recalled  the  very  first  Forest  Service  manual-  -small  enough 
to  fit  into  every  ranger's  shirt  pocket,  yet  containing  everything  foresters 
needed  to  know  to  do  their  jobs. 

'Why  is  it  that  when  we  have  a  problem,'  the  other  forester  asked, 

'the  solution  is  always  to  add  something— a  report,  a  system,  a  policy— but 
never  take  something  away?' 

The  first  replied:  'What  if ...  we  could  just  start  over?'  [Executive 
Summary,  1993] 

Reducing  cost  and  improving  customer  service  in  the  government  will  require  a 
systematic  approach  to  process  redesign  with  a  focus  on  dramatic  change.  The 
alternatives  in  this  thesis  represent  dramatic  change,  capable  of  increasing  process 
performance  and  improving  customer  service.  The  focus  is  to  eliminate  non-value  added 
processes  through  a  systematic  redesign  approach.  Using  this  systematic  approach, 
redesign  alternatives  are  developed  for  the  MPDP,  which  if  implemented  can  result  in  the 
reduction  of  value  chains,  lower  cost,  shorter  document  cycle  time,  and  an  increase  in  the 
quality  of  customer  service. 
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